[BUG] SDK default mode: background Task Bash denied without canUseTool; parent Bash then stays dead (regression of #27203)

Summary

In the Claude Agent SDK with permission_mode: "default" and a canUseTool callback that allows Bash, background Task subagents still receive hard denials for Bash. After that, the parent/main agent also starts getting the same denial for every Bash call (including no-ops), while Read/Write/Edit/Glob/Grep continue to work.

This matches the symptom cluster documented in https://github.com/anthropics/claude-code/issues/27203 (closed as stale/not_planned by github-actions without an Anthropic resolution). We are still reproducing it on current Agent SDK pins (claude-agent-sdk >=0.2.106,<0.3).

Please treat this as a fresh tracking issue; #27203 is locked.

Environment

• Package: claude-agent-sdk Python, range >=0.2.106,<0.3
• ClaudeAgentOptions.permission_mode = "default"
• can_use_tool callback: allowlist includes Bash and returns PermissionResultAllow for it
• allowed_tools also includes Bash
• Host: Linux (unattended Docker agent container; no interactive TTY / permission UI)
• Model: Claude Sonnet (cloud agent dispatch)

Observed behaviour

1. Early in a long session, main-agent Bash works (git status, git show, etc.).
2. A background Task subagent (run_in_background / local_agent background task) runs extraction work and hits Bash denials with:

> 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.

1. Immediately afterward, the main agent gets the identical denial for:

• git status --short (read-only)
• true (no-op, no filesystem side effects)
• sequential calls (not only parallel batches)

1. Non-Bash tools remain healthy (Read/Write/Edit/Glob/Grep/MCP).
2. Redispatch that resumes the same Claude session_id keeps the poisoned Bash transport. Only a force-fresh session (no resume) temporarily restores Bash — until the next background Task uses Bash again.

Evidence from one production-like run

• Agent run id: 01KY0N1JQ5Y63VR1D6J4CC5DXW
• Claude session_id (stable across redispatches): 8ca4fe1e-eb20-4c09-9b1e-da47f0b2792a
• Transcript denial count for the STOP message: 18
• Example denied commands (after background Task activity):
• find …/.storybook -maxdepth 1 -type f
• rm -rf … (denied; no files changed)
• cd … && git status --short (denied twice, sequential)
• true (denied)
• Earlier in the same session, Bash succeeded (e.g. git status --short, git show).
• Our allowlist deny path was not involved: zero not allowlisted results in the transcript.

Expected

• Background Task Bash permission requests are routed through the SDK canUseTool callback (or otherwise inherit parent allow rules).
• A denial / internal short-circuit in a background agent must not permanently disable Bash (or MCP) on the parent session for the rest of that session_id.

Actual

• Background Bash is denied with a fabricated “user doesn't want…” message without our canUseTool denying it.
• Parent Bash then fails the same way until session restart / force-fresh.

Related

• https://github.com/anthropics/claude-code/issues/27203 (locked; stale-closed; reporter root-cause notes still apply)
• https://github.com/anthropics/claude-code/issues/23983 (open; PermissionRequest hooks / subagents)
• https://github.com/anthropics/claude-code/issues/38859 (stale-closed; background agents + Bash permissions)

Workaround we use

Supervisor setting allow background Bash default OFF: deny Bash when ToolPermissionContext.agent_id is set (Task/subagent). Main-agent Bash remains allowed. Operators flip the setting ON only after verifying this issue is fixed.