Sub-agent dispatch denies Bash with tengu_harbor_permissions=true (regression 2026-05-03)

Summary

Sub-agents dispatched via the Agent tool (subagent_type: "general-purpose", run_in_background: true) receive a "Permission to use Bash has been denied" response on their very first Bash tool call, with no opportunity for the parent or a human to approve. Started occurring 2026-05-03; sub-agent dispatch had worked reliably for months prior.

Verbatim error from sub-agent's tool_result

Permission to use Bash has been denied. IMPORTANT: You *may* attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat. But you *should not* attempt to work around this denial in malicious ways, e.g. do not use your ability to run tests to execute non-test actions. You should only try to work around this restriction in reasonable ways that do not attempt to bypass the intent behind this denial. If you believe this capability is essential to complete the user's request, STOP and explain to the user what you were trying to do and why you need this permission. Let the user decide how to proceed.

is_error: true on the tool_result. Message is Bash-specific (other tools like Read/Grep/Glob remain available to the sub-agent).

Suspected cause

Local ~/.claude.json shows cachedGrowthBookFeatures.tengu_harbor_permissions: true. The "harbor" codename appears to refer to a new permission system rolled out via GrowthBook. Other related flags currently true in our cohort: tengu_harbor: true, tengu_harbor_ledger: [...], tengu_flint_harbor_share: true. We had tengu_disable_bypass_permissions_mode: false and tengu_mcp_subagent_prompt: true (so we are NOT in the cowork-affected cohort of #55712, which has different symptom).

Workaround attempted

• Edited ~/.claude.json to set cachedGrowthBookFeatures.tengu_harbor_permissions = false and restarted Claude Code session.
• Will update this issue with whether the local override survived GrowthBook re-fetch on startup, or whether the flag was forcibly reset.

Reproduction

1. Open an interactive Claude Code session with tengu_harbor_permissions: true (the default for the affected cohort).
2. Dispatch a sub-agent via Agent tool: subagent_type: "general-purpose", run_in_background: true, prompt that requires Bash on the first tool call.
3. Observe: sub-agent receives the verbatim denial above instantly; never has a chance to attempt the command.

Environment

• Claude Code: 2.1.126 (downgrade test to 2.1.123 inconclusive — symlink swap doesn't affect already-running parent process; symptom persists across what version we observed)
• Platform: Linux 6.8.0 (Ubuntu)
• Sub-agent type: general-purpose
• Parent permission mode: default interactive (parent has a 970-entry settings.local.json allowlist that does NOT appear to propagate to sub-agents)

Lived experience

Founder reports months of working sub-agent dispatch (parallel background work for typecheck/test/seed/PR-creation kinds of tasks) prior to today. Today's regression appears to coincide with multiple other sub-agent / agent-tool issues being filed (#55708, #55709, #55712, #55724) — suggests a coordinated server-side rollout (likely GrowthBook flag flip).

Related issues

• #55712 — Cowork mode sub-agent spawning broken; same root-cause mechanism (GrowthBook flag controlling sub-agent behavior), different symptom.
• #55708 — Agent tool isolation worktree issue.
• #55709 — Agent tool docstring references unavailable SendMessage.
• #55724 — Agent isolation worktree parallel agents lose work.

🤖 Generated with Claude Code