[Bug] Experimental CreateTeam: peer agents not inheriting workspace auto-approval for sandbox bash and repo filesystem operations

Bug Description

# /bug report — Experimental CreateTeam peer-agent auto-approval regression Title: Experimental CreateTeam regression: peer-agent tool operations (sandbox bash AND file Read/Write/Edit inside the working repo) are not covered by the workspace auto-approval the main thread gets — every peer action routes an approval prompt Summary: With the experimental agent-teams feature enabled (CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1), a peer/team-member agent created via CreateTeam does not inherit the main thread's workspace auto-approval context. Two distinct, sandbox/permission-safe operation classes that run without any prompt on the main thread instead route an approval prompt when performed by a peer: 1. Sandbox-safe bash — despite sandbox.autoAllowBashIfSandboxed: true (which correctly silences the main thread), a peer's git status/ls/grep prompts. 2. Filesystem ops on the working repo — Read, Write, and Edit on files inside the repository Claude is running in prompt for a peer, even though those paths are the working directory and are already covered by permissions.allow / additionalDirectories. Notably even plain Read of a repo file prompts — a peer cannot inspect the code it was assigned to review without interrupting the user. The identical operation auto-approves on the main thread but prompts from a peer. This is peer-agent-local and reads as an experimental-CreateTeam regression in how the workspace permission/auto-approval context is propagated per-agent — not standard /sandbox or standard permission behavior. This is not worked around by subagents: Standalone Task subagents are not a viable fallback, because (a) the regression is specifically in peer-agent-local auto-approval (sandbox bash + working-dir filesystem), and (b) Task subagents do not provide the peer coordination (shared task list, inter-agent messaging) that CreateTeam exists to provide. The only mitigations we found are hand-built proxy protocols: route all peer bash through the lead (peer sends a request message, lead runs it on the main thread, returns output via file), and route all peer edits through the lead (peer writes an edit descriptor to a shared file, lead applies it via a separate standalone agent). That is exactly the manual overhead the feature is supposed to eliminate. Minimal repro (one lead + one peer): 1. In settings, enable the sandbox with sandbox.autoAllowBashIfSandboxed: true, and confirm the working repo is under permissions.allow / additionalDirectories. Baseline: in the main thread, git status, reading a repo file, and editing a repo file all run with no approval prompt. 2. Set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. 3. CreateTeam with a single peer member (e.g. one cpp-developer). 4. From the lead, send the peer a task that requires: (a) one sandbox-safe bash command (e.g. git status), (b) a Read of a repo source file, and (c) an Edit to a repo source file. 5. Observe: each of the three operations routes an approval prompt to the user, despite autoAllowBashIfSandboxed: true, the command being sandbox-safe, and the files being inside the configured working directory. Expected behavior: A peer agent should inherit the same workspace auto-approval as the main thread — sandbox-safe bash auto-approved under autoAllowBashIfSandboxed, and Read/Write/Edit within the working directory / configured allow-list auto-approved — so no prompt is routed for these. Actual behavior: Peer agents are excluded from both auto-approval paths. Sandbox-safe bash and working-repo filesystem ops (including plain reads) all prompt. No setting or permission mode extends the auto-approval to peers (bypass-permissions mode is disabled in this environment). Secondary symptom observed in the same session (may share a root cause): Peer agents also frequently returned to idle (idle_notification, idleReason: "available") without delivering the requested result (requiring re-prompts), and inter-agent SendMessage delivery was delayed/out-of-order/batched (replies arriving after the lead had already acted; multiple stale idle notifications delivered together). Impact: Without peer-agent auto-approval for bash and working-repo file operations, a coordinated team cannot run hands-off — every peer action interrupts the user, including read-only code inspection. This blocks the experimental CreateTeam workflow for its intended use (here: processing PR-review findings through a developer/reviewer/architect team) and forces hand-built bash-proxy and edit-proxy workarounds. Frequency: Consistent — every peer bash command and every peer file Read/Write/Edit, in every session with teams enabled. Environment: - Claude Code 2.1.167 - Models: claude-opus-4-8 and claude-sonnet-4-6 - Platform: Linux - Flags/settings: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, sandbox.autoAllowBashIfSandboxed: true, working repo under permissions.allow / additionalDirectories, bypass-permissions mode disable…
Note: Content was truncated.