[BUG] Parked subagent tool calls time out after exactly 600s and are reported as "The user doesn't want to take this action right now"

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?

When a session ends up served by more than one ccd-cli process (the original process still alive + a new one started with --resume=<same-session-id>), the subagents running inside the original process keep executing but lose their channel. Each of their tool calls then waits exactly 600 s to be adopted, is not adopted, and aborts with reason: "background".

The harness maps that abort to the human refusal message:

The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed.

No user made any decision, and no permission rule was involved. The session was in bypassPermissions throughout, and Read/Grep/Glob are explicitly allowed in our managed settings.

Why this is worse than a hang or a crash: the leaf agent cannot distinguish an infrastructure abort from a real denial. In our run, agents that could not read files concluded the files were absent and reported them as such — producing false factual claims from an agent that behaved correctly given what it was told. A crash or a plain AbortError would have been safe. A misattributed refusal is not: the message actively instructs the model to stop and wait for a user who was never asked.

We only caught it because the timing was suspicious. A shorter timeout would have made this essentially undetectable.

What Should Happen?

A tool call aborted because its session was backgrounded should never be reported as a user decision.

In order of value:

1. Stop attributing background aborts to the user. Emit a distinct, honest message (e.g. "This tool call was aborted because its session was backgrounded and not adopted within 600 s"). Anything truthful is enough — the leaf agent can then report an infrastructure failure instead of inventing a factual conclusion. This alone would have prevented all of our damage.
2. Fail fast when the agent is already parked instead of paying 600 s per call. One affected agent spent ~2 h emitting calls that could never succeed.
3. Prevent or surface duplicate session serving — refuse or warn when --resume=<id> targets a session whose original process is still alive.

Error Messages/Logs

The message the agent receives, verbatim:


The user doesn't want to take this action right now. STOP what you are doing and wait for
the user to tell you how to proceed.


Relevant constants from the shipped bundle (identical in 2.1.201 and 2.1.209):


SUBAGENT_PARK_REASON      = "subagent-park"
RECOVERY_ABORT_TIMEOUT_MS = 600000          // matches the measured 600.00s exactly

// abort → message mapping:
f(e, signal) { return isAbortError(e) && signal.aborted && reason(signal.reason) === "background"
               ? REFUSAL_MESSAGE            // "The user doesn't want to take this action right now..."
               : normalError(e) }

// the misclassification:
isUserAttributableAbortKind("background") === true


A process-level backgrounding is classified as *user-attributable*, so it is rendered as a human refusal. That classification looks like the actual defect.

Measured evidence from a run of ~240 subagents (Workflow tool, `spawnDepth: 1`):

- **5 agents affected, 41 tool calls aborted.** Delta `tool_use` → `tool_result`: **600.00–600.01 s on every single one** (σ ≈ 0.01 s). Tools: `Read`, `Grep`, `Glob`.
- **Not path-dependent:** one agent read 115 files successfully, then *every* subsequent call failed — including a 5-line read of a small file in the project root. Paths with and without special characters behaved identically.
- **Not subagent-specific:** the main session was hit too — an `Edit` returned the same message 600 s later, to the second.
- **In-process tools unaffected:** `StructuredOutput` returned in 0.02–0.06 s throughout, including inside the affected agents. Only tools crossing the channel hung.
- **Clean control:** the same workflow, relaunched from the process that still held its channel, ran ~155 agents with **zero** occurrences.

Steps to Reproduce

Honest caveat first: we could not determine the exact trigger of the parking windows (they began at different times for different agents). What follows is the condition we observed and were able to correlate, not a guaranteed recipe.

1. Start a long-running session that spawns many subagents via the Workflow tool (spawnDepth: 1), each doing file reads (Read/Grep/Glob).
2. While the workflow is still running, get the session served by a second process: start a new one with --resume=<same-session-id> while the original ccd-cli process is still alive (in our case the original never exited; it kept running with frozen CPU and no children).
3. Observe the subagents still executing inside the original process. Their tool calls now hang for exactly 600 s and return the refusal message above, indefinitely, without recovery.
4. Contrast: relaunch the same workflow from the process that holds the live channel — zero occurrences.

Diagnostic shortcut for anyone hitting this: measure the delta between tool_use and tool_result in the transcript. If it is 600 s to the centisecond, it is this — not a permission decision.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.209 (ccd-cli, remote dev server) — CLI 2.1.201

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Version note: the incident was observed on 2.1.209 (server) / 2.1.201 (CLI). Not re-verified on 2.1.211, which was released afterwards — but the changelogs for 2.1.202→2.1.211 list no fix related to subagent parking, aborted tool calls, or this message, so the defect is very likely still present. The constants above are verifiable in any install.

Related: #19039 (orphaned processes sharing a resume session id; closed as duplicate) reports the same root condition without this symptom.

Environment details: permissionMode: bypassPermissions (verified in all 11 transcript samples, including the resume). Permissions resolved via --permission-prompt-tool stdio. Managed settings allow Read/Grep/Glob. PreToolUse hooks verified not involved: our load-protocol hook exits 0 for read tools before any check, and its own deny carries a different message. Ubuntu 24.04, Linux 6.8.

Note on evidence sharing: the raw workflow journal and transcripts contain third-party client data, so I can't attach them — they can't be anonymised without ceasing to be the evidence. What I can share is the derived measurement: per-call tool_use → tool_result deltas, which is where the signal actually is (600.00 s across 41 independent calls, on three different tools, in two different processes).