[BUG] 2.1.114 regression: background subagents cannot write to paths listed in permissions.allow — works in 2.1.112

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?

2.1.114 introduced a regression: background subagents (spawned via Agent tool with run_in_background: true) cannot use Write/Edit tools or Bash write commands (mkdir, echo >, touch, etc.) against paths explicitly listed in permissions.allow. The denial is immediate, silent, and happens before the allowlist is evaluated.

Foreground subagents on 2.1.114 still work because the interactive permission prompt surfaces. Read commands (cat, ls, python --version) also work in background. Only writes are blocked.

What Should Happen?

Background subagents should consult permissions.allow the same way foreground subagents and the main session do. When a write command (Bash mkdir/echo/touch, or Write/Edit tool) targets a path covered by an allow rule, the operation should execute without prompting and without denying.

This is the documented behavior per https://code.claude.com/docs/en/sub-agents — subagents inherit the permission context from the main conversation, and explicit allow rules should be honored regardless of foreground/background mode.

Error Messages/Logs

Background subagent receives this on every write attempt, with no interactive prompt and no entry in transcript explaining why:

  "Permission to use Bash has been denied"

For Bash mkdir example:
  Command attempted: mkdir -p C:/IA_Workspace/level2agent-engine/.claude/handoff
  Allowlist entry present: Bash(mkdir:*)
  Result: denied without prompt

For Write tool example:
  Path attempted: C:/Users/b70_r/.claude/results/handoff.md
  Allowlist entry present: Write(//c/Users/b70_r/.claude/results/**)
  Result: "Permission to use Write has been denied"

Read commands in the same subagent succeed silently (cat, ls, python --version all return correct output). The denial is write-specific.

Steps to Reproduce

1. Install Claude Code 2.1.114 fresh in VSCode.

1. Confirm permissions.allow in ~/.claude/settings.json includes a Write rule for some path, e.g.:

"Write(//c/Users/me/.claude/results/**)"

1. From the main session, spawn a subagent with the Agent tool using run_in_background: true. Use any agent definition that doesn't declare permissionMode (so it inherits default).

1. Brief the subagent to perform: Write a short file to the allowed path.

1. Observe: subagent receives "Permission to use Write has been denied" without any interactive prompt surfacing to the user. The denial is immediate.

1. As control: spawn the same subagent in FOREGROUND (run_in_background omitted/false). The interactive prompt appears, user can approve, and the Write succeeds.

1. As control: from the SAME machine in a session that was started before the 2.1.114 install (still on 2.1.112), repeat steps 3-5. Background subagent Write succeeds without prompt, as expected. Same machine, same settings.json file.

Additional reproducer for Bash:
3b. Brief the subagent to run: mkdir -p /some/new/path
4b. Confirm Bash(mkdir:*) is in allow.
5b. Observe: same "Permission to use Bash has been denied" pattern.

Tested across multiple agent definitions (debug_review_code with model: haiku; frontend_vanilla_wordpress with no model declared, inheriting opus). Same result for both: read OK, write denied.

Binary versions coexisting on disk:

• C:/Users/b70_r/.vscode/extensions/anthropic.claude-code-2.1.112-win32-x64 (works)
• C:/Users/b70_r/.vscode/extensions/anthropic.claude-code-2.1.114-win32-x64 (broken, installed 2026-04-17 23:12)

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.112

Claude Code Version

2.1.114

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Tests performed during diagnosis

Test 0 — Discarded bypassPermissions workaround as unsafe:
The known workaround for the related pre-existing bug #40502 (permissionMode: bypassPermissions in subagent frontmatter) was tested and rejected because it disables the entire permission resolver — including deny rules for destructive commands. Per project safety policy, no destructive auto-approval allowed in background.

Test 1 — Baseline, pre-upgrade session (2.1.112):
Background subagent executed mkdir -p C:/tmp/perms-check && echo test > file.txt && cat file.txt && python --version.
Result: all 4 steps OK, silent success.
Conclusion: 2.1.112 runtime propagates permissions correctly to background subagents.

Test 2 — Same test from a fresh session (2.1.114), parallel Bash calls:
Background subagent executed the same 4 Bash commands in parallel.
Result: Step 1 mkdir denied by harness. Steps 2-4 cancelled in cascade (not individually prompted).
Conclusion: denial happens at the permission-system level, not per-command.

Test 3 — Incrementally removed suspicious allowlist entries:
Removed 11 entries added the previous day (all Write(//c/...) and Edit(//c/...) with double-slash prefix, plus a specific Bash(python ... --full) entry). JSON remained valid at each step (verified with python -m json.tool).
Result: same denial pattern persists in fresh sessions. No single entry is the culprit.
Conclusion: the allowlist is not being consulted. This is not a malformed-entry issue.

Test 4 — Restored original settings.json byte-for-byte from backup:
The file that a fresh 2.1.114 session sees is identical to the one my 2.1.112 session loaded at startup.
Result: 2.1.112 session continues to work. Fresh 2.1.114 sessions still fail. Same file, different behavior.
Conclusion: settings.json is definitively not the cause. This is a binary/runtime change.

Test 5 — Serial execution (non-parallel) in background subagent:
Background subagent instructed to run the same 4 commands sequentially.
Result:

• Step 1 mkdir: "Permission to use Bash has been denied." (no interactive prompt)
• Step 2 echo >: "Permission to use Bash has been denied." (no interactive prompt)
• Step 3 cat file.txt: OK — returned "test"
• Step 4 python --version: OK — returned "Python 3.13.12"

Conclusion: the issue is not parallelism. Read commands pass in background; write commands are denied without prompt. The cascade in Test 2 was a side effect, not the root cause.

Test 6 — Added explicit Bash(mkdir:*), Bash(echo:*) and ~25 more common write commands to permissions.allow:
Result: identical denial pattern. Adding the exact command to the allowlist has no effect in background subagents on 2.1.114.
Conclusion: the allowlist is not consulted for background subagents in 2.1.114 — the block happens before allowlist evaluation.

Test 7 — Confirmed two binary versions coexist:

• C:/Users/b70_r/.vscode/extensions/anthropic.claude-code-2.1.112-win32-x64 (works)
• C:/Users/b70_r/.vscode/extensions/anthropic.claude-code-2.1.114-win32-x64 (broken, installed 2026-04-17 23:12)

My open session uses 2.1.112 (confirmed via CLAUDE_CODE_EXECPATH env var). Fresh sessions launched by VSCode now use 2.1.114.

Test 8 — End-to-end intermediate-file workaround attempt:
Implemented a workaround script ~/.claude/tools/save_handoff.py that takes a file written by the subagent in the cwd and moves it to ~/.claude/results/. The intent was to avoid Write outside cwd entirely (per #40502). 6 separate test runs across two model types (haiku, sonnet) and two agent definitions (debug_review_code, frontend_vanilla_wordpress), all in 2.1.114 sessions:
Result: the wrapper script never runs. Step 1 (mkdir <project>/.claude/handoff) is denied before any Write or Bash subprocess is invoked.
Conclusion: even the "Bash-only" path of the workaround is blocked. The denial fires on any Bash command from a background subagent that the harness classifies as a write — mkdir triggers it even though it doesn't write a file in the destination sense.

Summary table

| Scenario | Result |
|---|---|
| 2.1.112 session, background subagent write | ✅ OK |
| 2.1.114 session, background subagent write | ❌ Denied without prompt |
| 2.1.114 session, background subagent read (cat, python --version) | ✅ OK |
| 2.1.114 session, foreground subagent | ✅ OK (interactive prompt appears) |
| 2.1.114 session, allowlist modification | ❌ No effect |
| 2.1.114 session, intermediate-file workaround | ❌ Blocked at mkdir step |

The allowlist is not being consulted for write operations by background subagents in 2.1.114. The denial is immediate and silent.

Related issues / regressions

• #40502 (OPEN since 2026-03-29) — partial pre-existing version of this bug. 2.1.114 made it total.
• #50256 (OPEN, 2026-04-18) — background Bash dedup regression in same 2.1.112-114 range. Confirms active churn in the background-Bash subsystem.
• #50252 (OPEN, 2026-04-18) — 2.1.113 native binary regression (startup hang, WebFetch truncation). Same "works on 2.1.112, broken on 2.1.113+" pattern.
• #50200 (OPEN, 2026-04-17) — settings.json model setting not respected at session start in 2.1.113+. Suggests broader settings-loading regression.
• #50159 (OPEN, 2026-04-17) — Shift+Enter regression on 2.1.113. Generic "works on 2.1.112" pattern.
• #49663 / #49763 (CLOSED) — earlier permission-routing crashes in 2.1.111/112. The permission/agent subsystem has been under active churn for several releases.