Sub-agent Read/Edit denied on own worktree path despite bypassPermissions (v2.1.97)

Bug

In Claude Code v2.1.97, a sub-agent dispatched with isolation: "worktree" and mode: "bypassPermissions" has Read/Edit denied on paths inside its own assigned worktree. The Bash CWD half of the sibling bug was fixed in v2.1.97 (parent CWD no longer leaks into the sub-agent), but the file-tool half still trips intermittently.

Note: this is distinct from #37730 — that issue is about permission prompts on allowed tools. This one is about hard denials in bypassPermissions sub-agents, on paths the agent owns inside its assigned worktree.

Repro (captured 2026-04-09, deterministic for this session)

1. Parent session on main checkout at /home/bktaylor/loredex-orch, branch main.
2. Parent dispatches an Agent with isolation: "worktree", mode: "bypassPermissions", run_in_background: true.
3. Harness creates worktree at /tmp/claude-worktrees-bktaylor/agent-a5f4d899 on branch worktree-agent-a5f4d899.
4. Sub-agent's Bash CWD is correctly the worktree (pwd returns the worktree path — v2.1.97 fix working).
5. Sub-agent calls Read with file_path: /tmp/claude-worktrees-bktaylor/agent-a5f4d899/.claude/skills/orchestrate/SKILL.md (its own worktree path).
6. Read is denied with "Permission to use Read has been denied".
7. Same for Edit on the same path.
8. Interestingly, Read on the parent checkout path (/home/bktaylor/loredex-orch/.claude/skills/orchestrate/SKILL.md) succeeds in the same sub-agent, but Edit on that path is denied (correctly — it's outside the worktree).

So the denial pattern in this repro is:

| Path | Read | Edit |
|---|---|---|
| Parent checkout (/home/bktaylor/loredex-orch/...) | allowed | denied (correct) |
| Assigned worktree (/tmp/claude-worktrees-bktaylor/agent-a5f4d899/...) | denied (bug) | denied (bug) |

The sub-agent has to fall back to cat/python/sed via Bash on the worktree path to do its work. Bash runs fine on the same worktree path — the denial is specific to the file-editing tool surface.

Diagnostic data

$ claude --version
2.1.97 (Claude Code)

$ pwd
/tmp/claude-worktrees-bktaylor/agent-a5f4d899

$ ls -la /tmp/claude-worktrees-bktaylor/agent-a5f4d899/.claude/skills/orchestrate/
drwxrwxr-x  2 bktaylor bktaylor  4096 Apr  9 19:02 .
drwxrwxr-x 22 bktaylor bktaylor  4096 Apr  9 19:02 ..
-rw-rw-r--  1 bktaylor bktaylor 32385 Apr  9 19:02 SKILL.md

$ stat /tmp/claude-worktrees-bktaylor/agent-a5f4d899/.claude/skills/orchestrate/SKILL.md
  Access: (0664/-rw-rw-r--)  Uid: ( 1001/bktaylor)   Gid: ( 1001/bktaylor)

$ id
uid=1001(bktaylor) gid=1001(bktaylor) groups=1001(bktaylor),27(sudo)

$ git -C /tmp/claude-worktrees-bktaylor/agent-a5f4d899 branch --show-current
worktree-agent-a5f4d899

File permissions, ownership, and process uid are all consistent — the filesystem allows the access. The denial is inside the Claude Code tool-permission layer, not the OS.

Expected

A sub-agent dispatched with isolation: "worktree" and mode: "bypassPermissions" should be able to Read/Edit/Write/Glob any path inside its assigned worktree without denial.

Actual

Read and Edit hard-deny on paths inside the sub-agent's own worktree. Bash works on the same paths. The agent has to route all file edits through Bash+python/sed, which bypasses the auditability of the file-tool call surface.

Environment

• Claude Code v2.1.97
• Linux 6.12.76-linuxkit, Ubuntu
• Dispatch: Agent tool with isolation: "worktree", mode: "bypassPermissions", run_in_background: true
• Parent worktree at /home/bktaylor/loredex-orch (main checkout), sub-agent worktree at /tmp/claude-worktrees-bktaylor/agent-*

Related

• #37730 (related but distinct — permission prompts on allowed tools in sub-agents, not hard denials with bypassPermissions)
• Downstream tracking issue in our codebase: loredex #7073
• Upstream v2.1.97 changelog entry that fixed the Bash half of this bug