permissions.blockReadsOutsideWorkingDirectories ignores additionalDirectories from project and local settings

Status Open
Reported on v2.1.263
Maintainer reply None cached
Activity 2 comments · opened Sep 7, 2026

Environment

  • Claude Code 2.1.263 (CLI and Claude desktop app 1.46388.4, macOS 25.6)

Setup

  • User settings (~/.claude/settings.json): permissions.blockReadsOutsideWorkingDirectories: true and permissions.additionalDirectories: [A, B]
  • Project .claude/settings.json (trusted; hasTrustDialogAccepted is true, and the trust dialog was re-shown and accepted after resetting the flag): permissions.additionalDirectories: [C, D] (absolute paths)
  • Also tried an untracked .claude/settings.local.json with the same [C, D]

Observed

  • The session's environment header lists A, B, C and D as additional working directories, so the settings are being read.
  • Read/Grep/Glob refuse files under C and D with: ... is outside <cwd>, A, B; the permissions.blockReadsOutsideWorkingDirectories setting blocks reads outside the working directories. Ask the user to add the directory with /add-dir, or to remove that setting. Only cwd, A and B are listed as allowed.
  • The Bash sandbox's read allow-list (allowWithinDeny) also contains only cwd, A and B, so cat under C fails with Operation not permitted.
  • /add-dir C in the same session works.
  • Same result in freshly started sessions, with the project file tracked in git and with the local file untracked.

Expected (per docs, permissions.md "Working directories" and "Project allow rules and workspace trust")

  • Project/local additionalDirectories apply once trust is accepted, and files there are readable without prompts. The read fence should include them.

Impact

  • Unattended scheduled sessions cannot use project-declared additional directories at all while the read fence is on, since /add-dir needs an interactive session.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗