[BUG] Claude Agents has buggy behaviour with agent invocation via CLI

Do not use the "-p" parameter.

The combination of issues here -- can't attach to a running background session, no way to grant mid-run permissions, burns tokens without human oversight -- is a real operational gap. When a background agent can't prompt for permission and has no fallback path, it either halts silently or keeps trying more expensive alternatives, which is how 70% of a 5h quota disappears on what should have been a 15% task.

A few observations from running background agents at some scale:

On the session-attach hang. The "hover + Enter / right arrow" UX in claude agents failing while the session is still processing a prompt is likely a lock contention issue: the session's event loop is occupied and the attach path is waiting on a mutex that won't free until the current turn completes. From a user perspective this is invisible -- the cursor just sits there. Even a "session busy, try again when this turn finishes" error would be better than a silent hang.

On the permission-without-attach problem. This is the harder structural issue. If a background agent hits an unexpectedly broad tool use (e.g. a file delete it wasn't explicitly authorized for) and the human can't see the prompt, the agent either fails or skips the action silently. Neither is right. A lightweight notification surface -- even just a macOS notification with "Approve / Deny / Attach" -- would catch the majority of these before they burn tokens or skip important steps.

On the token burn. The 70% overage pattern in your report matches what happens when an agent is trying to prompt for permissions, gets no response, interprets silence as "keep going", and escalates to more expensive sub-tasks trying to work around the blocked step. A hard per-session token cap in background mode (user-configurable, default conservative) would stop this.

(disclosure: building Claudeverse, a control plane for Claude Code multi-agent workflows -- permission routing and per-session spend guardrails are directly in scope)

Seeing a variant of this on ordinary session switching (not just permission-blocked --bg-launched sessions): selecting an existing session from the agent list blanks the screen and shows "Waiting for session to redraw… Ctrl+Z to detach" — same tail message as reported here, worded as "waiting" rather than "can't," and in my case it does eventually resolve and load normally after a delay rather than getting permanently stuck.

One additional detail: intermittently, instead of rendering that text cleanly, the screen displays raw/unescaped control characters in its place — suggesting a malformed or unconsumed terminal escape sequence in this redraw path (possibly related to #72175, a different but similar leaked-escape-sequence bug during TUI redraw).

Also possibly related: #73631, which traces a different cause — stale "done" sessions accumulating in agent view — that may share this same redraw code path when switching sessions, worth checking whether the two "waiting"/"can't" message variants share a root cause even when triggered differently.

The control-character sequence I'm seeing (both standalone and layered under the "waiting to redraw" message) is ^[[I — i.e. \x1b[I, the standard xterm focus-in report (DEC mode 1004, \x1b[?1004h). Its counterpart \x1b[O (focus-out) is a subsystem this codebase already actively uses — I can see [presence] terminal focus → blurred in --debug-file output elsewhere, confirming focus-event-reporting is enabled and monitored.

That suggests a likely root cause: whatever's handling terminal input during the "waiting to redraw" state isn't running its normal escape-sequence parser, so an incoming focus-in report (\x1b[I) — sent by the terminal any time the window regains focus while mode 1004 is armed — passes through unconsumed and renders as literal ^[[I instead of being silently handled.

Do not use the "-p" parameter.

@xu00wei Thanks for the help, I will do that until the bug is fixed :3

I'm getting Waiting for session to redraw… Ctrl+Z to detach by running claude --model claude-sonnet-5 roughly once a day, with 2.1.202 (Claude Code), not using agents explicitly.

I think my Waiting for session to redraw… Ctrl+Z to detach is related to the choice of left arrow to enter the agents mode https://github.com/anthropics/claude-code/issues/64657 - it's easy to press that arrow by mistake, and then sometimes the Waiting for session to redraw… Ctrl+Z to detach hangs.