Sign up
View stargazers13Sign up

Claude: permission checks from a background subagent are denied with "no active turn" once the parent turn has ended#20339

opened7d agobyAArchitektApx

What happened

Subagents in Claude threads often can't use tools. Their tool calls fail with Claude V2 adapter has no active turn for this tool request., which wastes their work. This happens mostly when the agent launches many subagents.

Diagnosis

canUseToolEffect in ClaudeAdapterV2.ts (L7685-7692, unchanged on main at e58a485) denies every permission request while activeTurn is null. finalizeActiveTurn sets it to null when the root result arrives (L5866), but background subagents keep running in the same CLI process. From then on, any of their calls that reach canUseTool are denied. No runtime request is raised and the runtime policy isn't consulted, so even full-access threads deny.

  • Only calls the CLI doesn't approve on its own are affected: allow rules, read-only commands and Reads inside cwd still pass. Being outside cwd is not the trigger; ls <cwd> was denied as well.
  • Approval-required: reproduced. Requests are denied instead of being shown as approvals.
  • Full-access: affected when the CLI isn't really in bypass mode. With CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1, CLI 2.1.301 forces the startup mode to default. T3 records that mode (L8188) and switches back to bypass only on the next prompt (L8064). So the first turn of every new process runs in default, with the callback auto-allowing until the turn ends.
  • Foreground subagents are safe while their parent turn is open. When one is resumed with SendMessage, it runs in the background and is affected.
  • 11 root-level denials came right after a task_notification, in a turn the SDK started on its own. I couldn't reproduce these; it looks like a race.

Logs on this machine, Oct 9-16: 397 denials across 15 threads. 349 came from background subagents, 29 from resumed foreground subagents and 11 from the root agent. All of them fell between a root result and the next prompt.offer.

Steps to reproduce

  1. Start a new Claude thread in approval-required mode. Alternatively, use a fresh full-access thread with CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1.
  2. Have the agent launch a subagent with run_in_background: true that runs echo probe, Read /etc/hosts, cat /etc/hosts and ls <cwd>, then end its turn immediately.
  3. After the parent result, every call except echo fails with the error, and no approval appears.

With run_in_background: false, all calls pass.

Version

0.1.1-nightly.20261016.3203 (desktop, Nightly). The logs show the same denials in earlier nightlies back to Oct 9.

Environment

macOS 27.0.1 (arm64), T3 Code desktop (Node v24.21.0), Claude Code CLI 2.1.301, claude-agent-sdk ^0.3.276

Evidence

shell
1# approval-required child thread
2query.open permissionMode=default hasCanUseTool=true
317:06:13.527 ROOT Agent (run_in_background: true) accept config
417:06:16.051 result success <- activeTurn = null
517:06:21.779 sub Bash echo probe-bg-1 accept config
617:06:24.680 sub Read /etc/hosts reject user_reject "Claude V2 adapter has no active turn for this tool request."
717:06:30.545 sub Bash cat /etc/hosts reject user_reject (same)
817:06:32.862 sub Bash ls <cwd> reject user_reject (same)
9
10# full-access child thread, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1: same result
11query.open permissionMode=bypassPermissions allowDangerouslySkipPermissions=true
12system/init permissionMode=default
13
14# CLI alone
15$ claude -p --permission-mode bypassPermissions ...
16⚠ Permission mode forced to default — CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set (allowed_non_write_users hardening). ...

Related issues

#16484 and #19440 cover background subagents after the parent turn ends, but deal with UI updates and process exit, not permissions. #17633 is the same scrub setup with a different symptom. #15589 is the same "no active turn" shape in the Pi adapter.

Fix applied or workaround

For now I removed CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 from ~/.claude/settings.json, so full-access threads really start in bypass mode. I'd like to turn it back on once this is fixed, because it keeps credentials out of the subprocesses Claude starts. Approval-required threads are affected either way. The only other workaround is to use foreground subagents and not resume them with SendMessage.

Suggested fix: when no turn is active, decide the request from the thread's runtime policy, or raise it against the subagent's task, instead of denying it.

Filed by

Claude Code (claude-opus-5-5) in T3 Code, following the t3 triage playbook

JJulius Marminge7d ago

Note

Grok responding on behalf of Julius.

Confirmed on main, so this is accepted as a bug. In apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts, canUseToolEffect denies any permission request with "Claude V2 adapter has no active turn for this tool request." when activeTurn is null, and finalizeActiveTurn clears activeTurn when the root turn finishes. A background subagent that is still running in the same Claude process after that has its approval-requiring calls denied. No approval is raised and the thread's runtime policy is never checked.

The full-access part is a different story. The forced default mode comes from Claude Code itself: the CLI prints "Permission mode forced to default — CLAUDE_CODE_SUBPROCESS_ENV_SCRUB is set" even when you run it on its own, so that's upstream hardening rather than something T3 does. T3 just records the mode the CLI reports. Full-access threads only hit this denial path because of that setting.

Related: #19751 (the same "after the parent turn ends" gap, but for T3 MCP tools), #16484, #19440, and #17633 (another scrub side effect).

For now, workarounds are to use foreground subagents and not resume them with SendMessage, or to leave CLAUDE_CODE_SUBPROCESS_ENV_SCRUB unset if you want full-access threads to really start in bypass mode.

AArchitektApx7d ago
Synced from GitHub

Thanks for confirming! I agree the forced default comes from Claude Code itself. Two small corrections and one idea:

  1. T3 doesn't only record the reported mode. On the next prompt it switches the process back to bypassPermissions with setPermissionMode (ClaudeAdapterV2.ts L8064). That overrides the hardening anyway, but only from the second turn on, so the first turn of every new process behaves differently from the rest. T3 should either respect the forced mode or re-apply bypass right after init.
  2. The scrub isn't the only way full-access threads get here. One denial in my logs happened while the process was really in bypassPermissions, because the CLI still asked about a grep containing an em dash. The scrub makes it much more common, but even a correct bypass session can hit the deny path.

Idea: #19751 fixes the same gap for MCP tools by treating the caller as live while it has a running background subagent (pendingBackgroundTasks). The same check in canUseToolEffect could route these requests through the thread's runtime policy instead of denying them.

Jjamesvillarrubia3d ago
Synced from GitHub

Two more root-level cases, from another machine, on 0.0.46-nightly.20261013.3040. In both, the root agent's tool calls were denied in a turn the SDK started on its own after a background task notification.

  • 2026-10-18, one thread: AskUserQuestion was denied at 03:49:42Z and again at 04:34:13Z with Claude V2 adapter has no active turn for this tool request. No user message started the 04:34 turn. It began at 04:18:43Z, when the CLI dequeued a background shell's task_notification. After the second denial, the agent ended its turn with the question in its final text. T3 had no pending request for the thread, so the thread showed nothing waiting on the user. It sat 38 hours until the user sent another message.
  • 2026-10-19, another thread: 20 tool calls were denied between 03:06:08Z and 03:07:34Z while the agent retried.

A denied AskUserQuestion at the root wastes the call, and it also leaves a question the user never sees.

JJulius Marminge2d ago

Fresh triage: this is a bug report, not a reported exploitable vulnerability. Checked all 948 open issue titles for background subagents, permission checks, and "no active turn"; no same-symptom duplicate found. On current main b5a226e49c52ecab4ddc2d678a7012d97e651a6a, source inspection still finds the unconditional denial in canUseToolEffect when activeTurn is null. This is source evidence, not a new runtime reproduction. Stopped before implementation because fixing this path changes permission/approval handling and requires Julius under the triage hard stop. Leaving the issue open; no fix PR.

JJulius Marminge2d ago

Reproduced on current main 8acbefe in the Linux web dev client with Claude Opus 5.5 / CLI 2.1.303, Supervised mode. A native background Agent remained running after the parent result; Read /etc/hosts and Bash cat /etc/hosts then returned the exact no-active-turn error without an approval request. Existing fix #20347 is being preserved; its current tests and continuation handling need updates. The former permission-surface triage stop no longer applies.