additionalDirectories setting does not grant Read tool access to files outside project

[diogomatoschaves]

Bug Description

The additionalDirectories setting in .claude/settings.local.json does not grant the Read tool access to files in the specified directories. Files outside the project directory remain blocked with EPERM: operation not permitted even after being added.

Steps to Reproduce

1. Add a directory outside the project to additionalDirectories (either via /add-dir command or manually in settings):

   {
     "permissions": {
       "additionalDirectories": [
         "/Users/<user>/Documents/Screenshots/"
       ]
     }
   }

2. Attempt to read a file from that directory using the Read tool
3. Observe EPERM: operation not permitted error

Observed Behavior

• Read tool: EPERM: operation not permitted
• Bash with ls -la: Works (can stat the file, see metadata/permissions/size)
• Bash with cp: Operation not permitted (even with dangerouslyDisableSandbox: true)

This suggests the sandbox allows stat() but blocks open() for file reads in additionalDirectories paths.

Expected Behavior

After adding a directory via additionalDirectories, the Read tool (and Bash file operations) should be able to access files in that directory.

Environment

• Claude Code version: 2.1.59
• OS: macOS (Darwin 25.3.0)
• macOS Full Disk Access: Granted to terminal app
• Setting location: .claude/settings.local.json (project-level)

Notes

• The /add-dir command confirms the directory was added: Added /Users/<user>/Documents/Screenshots/ as a working directory and saved to local settings
• The directory in question (~/Documents) is macOS TCC-protected, but Full Disk Access is already granted to the terminal application
• This may be a sandbox profile issue where additionalDirectories paths are not being included in the sandbox allow-list for file reads

[github-actions]

Found 1 possible duplicate issue:

1. [BUG] EPERM: operation not permitted accessing ~/Library/CloudStorage/ despite Full Disk Access enabled #26981

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[cmlaverdiere]

+1 I've had this issue since claude code was released, it would be a big QOL improvement to finally see it fixed. Also applies to Bash commands like ls, find, grep, etc.

[jeffreyscottfrench]

Your additional directory is specified from project root. use a pattern like gitignore does, or ~/folder/ for the User directory.

[virtualian]

Additional evidence: ~/.claude/ hardcoded protection + additionalDirectories not persisting

Environment

• Claude Code: 2.1.87
• macOS: 26.4 (Build 25E246)
• Kernel: Darwin 25.4.0, arm64 (Apple Silicon, M4)
• Shell: zsh via Apple terminal

What we found

While investigating permission behaviour for ~/.claude/MEMORY/ (a directory used by a hook-based system that routinely reads/writes files there), we discovered several issues:

1. Blanket permission rules don't override ~/.claude/ protection

With both Write (blanket) and Write(~/.claude/**) (path-scoped) in ~/.claude/settings.json allow list, writes to ~/.claude/MEMORY/ still trigger the "Claude requested permissions to edit X which is sensitive file" prompt. The docs confirm this is hardcoded protection for .claude/, .git/, .vscode/, .idea/ directories, with only .claude/commands, .claude/agents, and .claude/skills exempt.

Tested with both tilde (~/.claude/**) and absolute (/Users/.../. claude/**) path forms in the allow list — neither overrides the hardcoded protection.

2. "Yes, and always allow access to MEMORY/ from this project" doesn't persist

When selecting option 2 on the permission prompt, nothing is written to disk. We verified:

• .claude/settings.local.json — unchanged
• .claude/settings.json (project) — unchanged
• ~/.claude/settings.json — unchanged
• ~/.claude/settings.local.json — unchanged
• Grepped all JSON files for additionalDirectories — zero matches anywhere

3. Binary analysis confirms the code path

Decompiling the Claude Code binary (~/.local/share/claude/versions/2.1.87), the persistence code for addDirectories should call J8("localSettings", { permissions: { additionalDirectories: [...] } }) which writes to .claude/settings.local.json. The code exists, but the write either fails silently or never reaches the persistence function.

Suspicion Root cause (updated 2026-03-29)

This appears to be two overlapping issues:

1. The additionalDirectories write is silently failing when triggered from the built-in sensitive-file confirmation prompt (option 2). The aJ7 function catches errors and returns false without surfacing them.

2. Even if additionalDirectories were written correctly, the macOS sandbox may not honour it — consistent with the original report in this issue. The sandbox profile likely isn't updated to include dynamically-added directories after startup.

The net effect is that the "always allow" option in the sensitive-file prompt is a no-op: it doesn't persist, and even if it did, the sandbox wouldn't enforce it.

Updated analysis: The macOS sandbox theory was wrong. All file operations succeed after user approval — a sandbox denial would produce access errors, not permission prompts. ~/.claude/ is already inside the sandbox (Claude Code reads its own config from there). The "sensitive file" prompt is purely application-layer UI logic, not OS enforcement.

The actual issues are:

1. additionalDirectories persistence silently fails — option 2 ("always allow") calls the write path but nothing reaches disk. The aJ7 function catches errors and returns false without surfacing them.

2. Even manually setting additionalDirectories doesn't override hardcoded .claude/ protection — we manually added "additionalDirectories": ["/Users/.../. claude/MEMORY"] to both project and user settings files. The permission prompt still appeared. The hardcoded sensitive-directory check for .claude/ runs before (or ignores) the additionalDirectories exemption.

Both bugs are in Claude Code's permission UI layer. The net effect: there is no way to auto-allow file operations under ~/.claude/ except for the three exempt subdirectories (commands, agents, skills).