Unattended `--bg` sessions can hang for hours on an unanswered auto-mode permission prompt, with no timeout and no way to see it

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

We run Claude Code unattended via claude --bg --continue (through our own third-party wrapper, Agent Desktop, which dispatches one persistent background session per project folder in default auto mode - not bypassPermissions). When an action needs auto mode's classifier review and the classifier declines to auto-approve it (in our case: category "Merge Without Review" for a local git merge), Claude Code correctly falls back to an interactive confirmation prompt - but a --bg session has no attached terminal for anyone to answer it. The session then just sits blocked, status:"waiting" / waitingFor:"permission prompt" in ~/.claude/sessions/<pid>.json, indefinitely. We measured one real occurrence stuck for ~8.5 hours before anyone noticed, and on 2026-09-28 six more recurrences 15-40 minutes apart across one evening on what looked like the SAME reviewed merge task - i.e. answering the prompt once does not appear to cover the rest of that task; it re-prompts again a short time later.

Three things we found while digging into this, which may be separate issues but seem related:

1. Several other reports (e.g. #97654) describe auto mode's denial/prompt rate rising sharply since 2.1.268; we're on 2.1.283 (bumped in our environment on 2026-09-26) and only started seeing this exact pattern on 2026-09-28.
2. The 2.1.282 changelog says "Changed auto mode so that, where its classifier review runs server-side, read-only and sandboxed shell commands also wait for that review" - we saw this directly: a plain git log/git diff branch-comparison loop (no writes at all) tripped the same block, not just the merge itself, and the block appeared to escalate across consecutive commands within one turn (a "consecutive actions blocked" counter climbing 3->4->5->6 in our session logs).
3. Several other users reported the server-side classifier intermittently returning "no verdict" on 2026-09-28 specifically (#97884, #97854, #97812, #49535) - if that outage was live during our window too, it would explain why even previously-fine read-only commands started getting blocked alongside the merge.

What Should Happen?

An unattended claude --bg session should never be able to sit blocked on an interactive permission prompt indefinitely with zero visible signal to anyone. Either: (a) an unanswered prompt in a --bg session should time out to a denial after a configurable interval, with the tool call receiving a clear, catchable error the agent can react to instead of a silent hang, or (b) a human's one-time approval of a specific action/category should hold for the rest of that session/task rather than re-firing every 15-40 minutes on what looks like the same reviewed action.

Error Messages/Logs

Claude Code version: 2.1.283 (also reproduced on our interactive install, 2.1.273)
OS: Windows 10 Pro 10.0.19045
Running via: `claude --bg --continue`, dispatched by a third-party Electron wrapper (not an Anthropic product)

Session state file at time of hang (~/.claude/sessions/<pid>.json):
{"status":"waiting","waitingFor":"permission prompt","statusUpdatedAt":<unchanged for hours>}

Recurrence log from an independent outside monitor (polls ~/.claude/sessions/*.json every 5 min, 2026-09-28, all times local):
16:57 stuck 6min
17:17 stuck 26min
17:32 stuck 41min
17:52 stuck 5min
18:12 stuck 6min
18:22 stuck 7min (resolved by manually running `claude stop <id>` then `claude --bg --continue` each time)

Same evening, a separate Claude Code session (ours, interactive, 2.1.273) had unrelated tool calls (a cross-session message to another local agent) denied with:
"Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Auto-Mode Bypass]."
on completely routine, previously-unblocked actions - consistent with the classifier-outage reports linked above rather than a genuine policy match.

Steps to Reproduce

1. Dispatch an unattended session in default auto mode: claude --bg (or --bg --continue) in a repo where the agent's task will eventually need a write-shaped git operation (e.g. merging a reviewed PR with a local git merge).
2. Let the agent reach that git merge step as part of its normal task.
3. Auto mode's classifier declines to auto-approve it (category "Merge Without Review" in our case) and Claude Code correctly falls back to an interactive confirmation prompt.
4. Because the session was dispatched with --bg, there is no terminal attached to answer that prompt - nobody sees it.
5. Check ~/.claude/sessions/<pid>.json for that session: status stays "waiting", waitingFor:"permission prompt" indefinitely - no timeout, no notification, the process just sits there. In our case this went unnoticed for ~8.5 hours once.
6. Even after a human finds it and answers once (claude attach <id>), a later unrelated read-only git command (e.g. plain git log/git diff) in the same or a later turn can trip the same block again within 15-40 minutes, repeatedly.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.283 (Agent Desktop's private CLI install); 2.1.273 on the interactive install used to investigate

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related prior reports we found (all closed as stale/not-planned, but the core gap is unresolved per their own comment threads):

• #64271 - same underlying mechanism (--bg stalls on a permission prompt with no non-interactive reply path). A 2026 comment there found that claude attach <id> CAN connect to a blocked --bg session and answer it live, and that the resulting grant is session-scoped (persists for the rest of that run) - useful, but still requires a human at a TTY, which defeats unattended automation.
• - #37913 - the exact feature request for a configurable permissionRequestTimeout (auto-deny after N seconds). Closed as stale with no implementation; still looks like the right fix for the unattended case specifically.
• - - #97654 / #97884 / #97854 / #97812 / #49535 - other reports from around the same date (2026-09-28) pointing at both a longer-term rise in auto-mode's denial rate since 2.1.268 and a same-day server-side classifier outage; raised here only because they may share a root cause with the recurrence pattern we saw.

We're not asking to reopen those - just flagging that this specific angle (unattended --bg sessions have zero bounded recovery path) still seems to be an open gap across all of them, and it's the part that's actually hurting us operationally (occasional multi-hour unattended stalls, invisible until an outside process happens to check).