[Bug]: Claude thread blocked by auto-mode denials ends as "Completed" instead of needing attention #18386

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Start a Claude thread with the permission mode set to Auto (Claude Code auto mode).
2. Get the auto-mode classifier to deny a tool call. The most reliable trigger I hit: the conversation contains detailed security findings (e.g. the agent read a TODO list describing open vulnerabilities, or is fixing an auth bypass). From then on the classifier refuses to assess further Bash calls ("cannot assess the action due to earlier conversation content"). A plain deny rule or any other classifier block behaves the same way.
3. The agent receives the denial as a failed tool call, can't proceed, and ends its turn.

Expected behavior

The thread signals that it needs me: a "needs attention" status (like a pending approval) instead of "Completed", a row such as "2 actions denied by auto mode" with the classifier's reason, and ideally a one-click "switch to Default / Full access and retry".

Actual behavior

The thread shows Completed and auto-settles. Nothing in the sidebar or the timeline distinguishes "finished the task" from "gave up because auto mode blocked it", so I only notice hours later when I open the thread. In Default mode the same action raises a permission prompt and the thread shows as waiting.

From the source (commit cafe620e):

• In auto mode no permission callback is installed (ClaudeAdapterV2.ts:1723-1727), and the classifier denies inside the CLI before canUseTool, so no runtime request is ever created.
• The SDK already reports these denials: every result message carries permission_denials ({tool_name, tool_use_id, tool_input}, visible in the replay fixtures), but no production code reads it; it only appears in tests and fixtures.
• terminalStatusFromResult (ClaudeAdapterV2.ts:2536-2569) looks only at abort reasons, API errors and is_error, so a successful result with denials becomes completed; ThreadSettlementService.ts:139-164 only holds back for pending requests, active runs or background work.
• The Grok adapter already turns an auto-mode block into a pending request (testkit/fixtures/grok_auto_blocked_command), so there is precedent.

Possible fix: in the result branch, read permission_denials, drop the tool-use ids T3 itself denied (ExitPlanMode capture, user declines, cancelled questions), and for the rest emit a system notice row and mark the run as needing attention so it isn't auto-settled. Caveat: the entries carry no reason or source, so the reason has to come from the matching tool_result error text.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261011.2967 (source references: cafe620e)

Environment

macOS 26 (Mac mini, T3 server running 24/7), Claude Code 2.1.296, Agent SDK 0.3.276, Claude Max subscription

Workaround

Switch the thread to Full access (or Default) by hand and send "continue". For threads that will touch security-sensitive content, start them in Full access.