[BUG] Background subagents still prompt or deny Read/Glob/Grep in git worktrees despite global allow rules

Preflight Checklist

• [x] I have searched existing issues. The closest previous issue was closed as not planned/stale: #38914
• [x] This is a single bug report
• [x] I am using the latest version of the CLI

What's Wrong?

Global allow rules for read/search tools do not behave consistently in git worktrees, especially for background subagents.

For example, a user may have this in global ~/.claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep"
    ]
  }
}

Those tool permissions appear to be inherited, but worktree paths still go through a separate allowed-directory/path gate. As a result, a session or subagent can still prompt or deny access when trying to use Read, Glob, or Grep inside an auto-created worktree path.

This is annoying in an interactive session, but it is worse for background subagents. A background Explore/Plan/read-only subagent may be running in an isolated worktree and trying to inspect the project with basic read/search tools. If the worktree path is not considered allowed, the subagent can hit a permission prompt or denial even though the user globally allowed those tools.

In background/subagent contexts, permission prompts are much harder to recover from. The failure looks like the agent cannot inspect the project despite the global allow rule.

Related issues:

• #38914: exact previous report for Read/Glob/Grep allowed globally but still prompting in git worktrees
• #28248: worktree permission scoping/path identity confusion
• #51286: additionalDirectories glob entries not consistently propagating to child subagents
• #47339: background subagents need a way to escalate permission requests to the parent session
• #32402: background subagents silently auto-deny permissions
• #47134: adjacent worktree-isolated agent denial under .claude/worktrees

What Should Happen?

A global allow for Read, Glob, and Grep should work consistently in git worktrees created or used by the CLI.

Auto-created worktree paths should either inherit the parent project's read/search allowance or be added to the allowed working directories for that session/subagent.

If the current behavior is intentional, the docs should make clear that bare global tool allows do not grant path access in worktrees, and that users must also configure permissions.additionalDirectories or path-scoped rules like Read(<path>/**).

Error Messages/Logs

The visible symptom is a permission prompt or denial for basic read/search access inside a worktree even though the corresponding tool is globally allowed.

In background subagent contexts this may present as the subagent failing to inspect files, silently denying the tool call, or returning incomplete results rather than recovering through an interactive prompt.

Steps to Reproduce

1. Configure global settings with bare read/search allows:

``json
{
"permissions": {
"allow": [
"Read",
"Glob",
"Grep"
]
}
}
``

1. Start a CLI session in a git repository.
2. Trigger a background/read-only subagent or worktree-isolated agent that uses an auto-created worktree.
3. Have the subagent inspect files in the worktree using Read, Glob, or Grep.
4. Observe that the subagent can still hit a permission prompt or denial for the worktree path, despite the global tool allow.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.126

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

The workaround is awkward because worktree paths are ephemeral, especially for background subagents. Adding each generated worktree path to permissions.additionalDirectories or writing path-scoped rules like Read(<path>/**) does not scale well for background agent workflows.