Sign up
View stargazersSign up

Approval-pending commands stay "Running" after a runtime-mode change fails their run#22957

opened9d agobySSimonLiu423

What happened

In a Claude thread, after the agent finished its task, the composer still shows "Running 2 commands mkdir -p /tmp/sysmon && cd /tmp/sysmon && for i in $(seq 1 1…" with a Stop button. Nothing is running: the commands ran and finished in a later run of the same thread, and no matching process exists on the machine. The banner stays.

Diagnosis

The two commands belong to a run that was closed by a runtime-mode change while their approvals were still pending. Their turn items were never terminalized, so they stay running forever.

Timeline (UTC) from the thread's provider event log, server trace and the state database:

  1. 14:58:46 / 14:58:48. Run 1 (Supervised) emits two Bash tool_use blocks. Each opens an approval runtime request, and each gets a command_execution turn item with status running.
  2. 14:58:49.226. While both approvals are pending, the user switches the thread to Auto (thread.runtime-mode.set) and sends a message (message.dispatch, 14:58:49.269).
  3. 14:58:49.528. The Claude query is closed (query.close), and run 1 is finalized as failed (completedAt 14:58:49.529Z). A new query resumes the session and run 2 starts.
  4. 14:58:50.906. The client's runtime-request.respond for the stale approval fails: RuntimeRequestService.respond → ProviderAdapterRuntimeRequestResponseError: Failed to respond to claudeAgent runtime request …. The runtime request rows end up resolved.
  5. In run 2, Claude re-issues both commands (new tool-use ids), and they complete normally. Run 2 completes at 15:02:36.

Final DB state for run 1: run failed, but its two command_execution items (toolu_01NnYJ…, toolu_01KHp5…) remain status = running, completedAt = null.

Why the banner shows them: selectShellPendingTurnItemRows (apps/server/src/orchestration-v2/ProjectionStore.ts ~L5858 at v0.1.1) returns every command_execution / dynamic_tool / subagent item with a non-terminal status. It excludes only items whose run is rolled_back, so items of a failed run are still reported as pending shell work.

Why they are never settled: writeFinalRunEvents (apps/server/src/orchestration-v2/RunExecutionService.ts ~L615) cascades terminal status to run-owned subagents (cascadeTerminalizeRunOwnedSubagents) but not to the run's command items. Leaving those open is presumably deliberate for real run_in_background shells, which can outlive their run. But these items never started: they were still awaiting approval when the run ended, so nothing will ever complete them.

A likely fix direction: when a run reaches a terminal status, terminalize (as interrupted or cancelled) its command and dynamic-tool items that were never started or were only awaiting approval, while leaving confirmed background tasks alone. Alternatively, the pending-shell query could ignore non-background items whose run is terminal.

Steps to reproduce

  1. Desktop app, Claude provider, thread in Supervised (approval-required) runtime mode.
  2. Ask for something that makes Claude issue two Bash tool calls in one assistant message (e.g. "monitor my system's CPU for 3 minutes").
  3. While both approval requests are pending, switch the composer's runtime mode to Auto and send a message ("just gave you auto access").
  4. Let the new run finish.
  5. Observe: the "Running 2 commands …" banner with Stop stays above the composer. In orchestration_v2_projection_turn_items, the first run's two command_execution items are still running while the run is failed.

(Reproduced once from logs, not yet re-run deliberately.)

Version

T3 Code (Beta) desktop app, server 0.1.1 (local server started ~8h before the bug; the triage CLI was also 0.1.1)

Environment

macOS 27.0.1 (darwin arm64, Apple M1), Node v26.8.2, Claude Code 2.1.306, model claude-opus-5-5

Evidence

shell
1# orchestration_v2_projection_runs
2run …:ordinal:1 claudeAgent failed requested 14:58:31.453Z completed 14:58:49.529Z
3run …:ordinal:2 claudeAgent completed requested 14:58:49.569Z completed 15:02:36.357Z
4
5# orchestration_v2_projection_turn_items (command_execution, run 1)
6toolu_01Qs4gEmhvBZoHSxnWa9g1s3 completed 14:58:41.434Z
7toolu_01NnYJERtKBvD4EJMDtFCEDd running 14:58:46.035Z completedAt=null # mkdir -p /tmp/sysmon && … top … sleep 7
8toolu_01KHp53LQDsorpQz6k2fqFEx running 14:58:48.070Z completedAt=null # ps -p … ; sysctl vm.swapusage …
9
10# provider event log
1114:58:48.079Z incoming message_delta stop_reason=tool_use
1214:58:49.528Z outgoing query.close
1314:58:50.283Z outgoing query.open permissionMode=auto resume=<same session>
1414:58:50.284Z outgoing prompt.offer "just gave you auto access"
15
16# server trace
1714:58:49.226 orchestrationV2.dispatch.once thread.runtime-mode.set Success
1814:58:49.271 orchestrationV2.dispatch.once message.dispatch Success
1914:58:50.902 orchestrationV2.dispatch.once runtime-request.respond Success
2014:58:50.906 RuntimeRequestService.respond Failure RuntimeRequestResponseExecutionError: Failed to respond to runtime request runtime-request:provider:claudeAgent:…
2114:58:50.907 ClaudeAdapterV2.respondToRuntimeRequest Failure ProviderAdapterRuntimeRequestResponseError: Failed to respond to claudeAgent runtime request …

Related issues

#16000 (runtime-mode change detaches the Claude session without the background-work check): the same trigger, but that issue is about killing live background work, not about approval-pending items left running. #16557 (failed run leaves the provider turn running): the same family (failure finalization doesn't terminalize child rows), but a different row type. #18188 ("Running" banner where Stop does nothing): there, the server already had the item completed and the client copy was stale; here, the server itself has it running. #21503 (send declines pending approvals) is web/mobile only and does not cover the runtime-mode detach path.

Fix applied or workaround

None applied. The banner is cosmetic; starting a new thread avoids it.

Filed by

Claude Code (claude-opus-5-5) via t3 triage

Ppsicilia51795d ago
Synced from GitHub

Also hitting this on 0.1.2 (Windows desktop app with its local server, plus the iOS app; claudeAgent / claude-opus-5-5). Details are in #25054, which was closed as a duplicate of this one. What it adds:

  • Supervised → Full access triggers it the same way as → Auto. The provider log shows query.close, then query.open with permissionMode: "bypassPermissions" and the same resume session.
  • MCP tools as well as Bash. For a stuck mcp__claude-in-chrome__navigate, the leftover item is a dynamic_tool, and the pill reads "Waiting on background task Navigate".
  • Frequency. Six occurrences in three days of normal use, every time the user answered an approval by switching the mode and typing "approved, you have full access". Each one shows the same sequence within about 50 ms: decline → run failed → new run.
  • Stale approval cards stay answerable. Cards for dead tool calls keep working buttons. That includes one from a plain steer, where the tool item itself was closed correctly. Tapping a card resolves the dead request, the agent never sees it, and the stuck item stays running. During a later Full access run, an old card looked like that run's own prompt.
  • The sidebar shows the thread as Waiting the whole time, as well as the composer pill.

Workaround: tap Allow or Decline first, then change the mode.