chenhg5/cc-connect · warning

tmux: permission requests are not supported

Error message

tmux: permission requests are not supported

What it means

The tmux agent drives a terminal via send-keys and parses pane output, so it has no mechanism to receive or answer permission prompts. RespondPermission therefore always returns 'tmux: permission requests are not supported'. The core engine calls this when the user clicks a permission button on a message routed to a tmux-backed session.

Source

Thrown at agent/tmux/session.go:179

					response := s.extractResponse()
					s.safeSend(core.Event{Type: core.EventResult, Content: response, Done: true})
					return
				}
			}
		}
	}
}

func (s *tmuxSession) safeSend(ev core.Event) {
	defer func() { _ = recover() }() // channel may be closed on session teardown
	select {
	case s.events <- ev:
	case <-s.ctx.Done():
	}
}

func (s *tmuxSession) RespondPermission(_ string, _ core.PermissionResult) error {
	return fmt.Errorf("tmux: permission requests are not supported")
}

func (s *tmuxSession) Events() <-chan core.Event { return s.events }

func (s *tmuxSession) CurrentSessionID() string { return s.sessionID }

func (s *tmuxSession) Alive() bool { return s.alive.Load() }

func (s *tmuxSession) Close() error {
	s.closeOnce.Do(func() {
		s.alive.Store(false)
		s.mu.Lock()
		if s.pollCancel != nil {
			s.pollCancel()
			s.pollCancel = nil
		}
		s.mu.Unlock()
		s.cancel()

View on GitHub (pinned to 4000b2338a)

Solutions

1. Don't send permission prompts to tmux-backed sessions — respond by typing the approval choice into the terminal via Send instead
2. Check engine routing: the permission card should only be offered for sessions whose AgentSession supports permission responses
3. If you need interactive permissions, use an agent adapter with RespondPermission support (e.g. claudecode) instead of the tmux passthrough

Example fix

// engine side: capability check before showing permission UI
if pp, ok := sess.(core.PermissionResponder); ok {
    showPermissionCard(chatID, pp)
} else {
    p.Reply(chatID, i18n.T(core.MsgPermissionNotSupported))
}

func supportsPermissions(sess core.AgentSession) bool {
    _, ok := sess.(interface {
        RespondPermission(string, core.PermissionResult) error
    })
    return ok // always true; instead gate on agent kind/capability flag
}
// better: gate on an agent capability flag, since tmux implements but rejects it

// Go
if err := sess.RespondPermission(reqID, result); err != nil {
    if strings.Contains(err.Error(), "not supported") {
        p.Reply(chatID, "This agent cannot process permission prompts; type your choice in the terminal.")
    }
}

When it happens

Trigger: Calling RespondPermission (directly or via the engine's permission-card buttons) on any tmuxSession, regardless of arguments.

Common situations: Platform shows generic permission UI because the session emitted a permission-like event path in the engine; user taps Allow/Deny on an old card after the session was switched to a tmux agent; misconfiguration mixing tmux with an agent that normally requests permissions (e.g. Claude Code).

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• antigravity: permission responses are only available in defa
• operation not supported by this platform
• acp: probe start %s: %w
• read existing Agy hooks %s: %w
• permission bridge environment is missing

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/5b3a5ba6485b16a1. Report an issue: GitHub.