[BUG] Sub-agents denied Read on paths outside project root despite explicit permissions.allow Read(...) rule

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?

Summary

Sub-agents (dispatched via the Agent tool) are denied Read tool access to file paths outside the project root, even when permissions.allow includes an explicit Read(<path>/**) rule covering those paths. The same Read calls succeed from the main session, and the same sub-agents can read paths inside the project root without issue. The denial appears to come from the harness's own permission layer (the error message reads "Permission to use Read has been denied"), not from macOS TCC.

The deny appears hardwired regardless of where the allow rule lives (project-level .claude/settings.json or user-level ~/.claude/settings.json).

Environment

• Claude Code extension: anthropic.claude-code-2.1.126-darwin-arm64
• Host IDE: Cursor (extension running as native binary)
• Platform: macOS 14.6 / Apple Silicon
• Cloud storage in test: OneDrive Business via macOS File Provider

What Should Happen?

What should happen

Sub-agents should consult permissions.allow Read rules the same way the main session does. When an allow rule explicitly covers a path, sub-agent Read on that path should succeed without prompting and without denying.

If the cross-boundary deny for sub-agents is intentional safety behaviour, please:

1. Document it in the settings.json reference so users know the deny exists
2. Provide an opt-in setting to override it for explicit Read-only paths — e.g.

``json
"permissions": {
"subagent_permissions": {
"allow_paths_outside_root": [
"/Users/me/Library/CloudStorage/OneDrive-Org/**"
]
}
}
``

Use case

Our orchestrator dispatches sub-agents that need to Read corporate reference material stored in OneDrive (historical IC meeting notes, ~6 GB across thousands of files). Pre-snapshotting into the project tree works as a workaround but doesn't scale and creates duplicate-data / staleness problems.

Tested workarounds — none successful

• ✗ Project-level .claude/settings.json Read(/path/**) rule — denied
• ✗ User-level ~/.claude/settings.json Read(/path/**) rule — denied
• ✗ Symlink from inside project to OneDrive path — same path-based deny
• ✗ macOS Full Disk Access for the claude binary — granted but doesn't help (the deny is at the harness layer, before TCC)

The only workaround that works is rsync-ing the data into the project tree, which has the drawbacks noted above.

Related

#50267 documents the same permissions.allow rules being ignored for Write operations in background sub-agents (regression in 2.1.114). Combined with this Read issue, there's a broader pattern of sub-agent permission rules not being consistently honoured. They may share a root cause.

Error Messages/Logs

Steps to Reproduce

Reproduction

1. Set up a project at /path/to/project/ containing a .claude/settings.json:

``json
{
"permissions": {
"allow": [
"Read(/Users/me/Library/CloudStorage/OneDrive-Org/**)"
]
}
}
``

1. Confirm the main session can read a file under that path:

Read /Users/me/Library/CloudStorage/OneDrive-Org/example.pdf → succeeds

1. Dispatch a sub-agent with the Agent tool (subagent_type: general-purpose) and ask it to perform the same Read on the same path
2. Observed: sub-agent gets "Permission to use Read has been denied" — immediate, no prompt
3. Move the rule to user-level ~/.claude/settings.json — same denial in sub-agents
4. Move the file inside the project root → sub-agent reads it fine. So the deny is path-based, not tool-based or content-based

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

anthropic.claude-code-2.1.126-darwin-arm64

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Cursor

Additional Information

_No response_