[BUG] Repo-level .claude/settings.json not loaded when session is rooted at a parent directory

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?

When a Claude Code session is rooted at a parent/workspace directory, any .claude/settings.json files inside subdirectory repos are silently ignored. Rules in those files — including deny rules — have no effect.

What Should Happen?

When Claude accesses a file inside a subdirectory that has its own .claude/settings.json, that file's rules should be loaded and applied for any operations within that directory.

Error Messages/Logs

Steps to Reproduce

1. Create a workspace directory and launch Claude Code from it:

/workspace/
└── .claude/
└── settings.json ← session root (no deny rules)

1. Inside the workspace, create a subdirectory repo with its own settings and a test file:

/workspace/
└── my-repo/
├── .claude/
│ └── settings.json ← contains deny rule
└── blocked.txt

1. my-repo/.claude/settings.json:

{
"permissions": {
"deny": ["Read(**/blocked.txt)"]
}
}

1. blocked.txt — any content.
2. With the session still rooted at /workspace/, ask Claude to read my-repo/blocked.txt.
3. Observe that the file is read successfully with no prompt or block — the deny rule in my-repo/.claude/settings.json was never applied.

Expected: The repo-level settings.json should be loaded and the read should be blocked.

Actual: The repo-level settings.json is silently ignored. Only the workspace-level settings file is loaded, regardless of which subdirectory the target file lives in.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.160

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Additional Information:

• This was discovered while investigating the first bug (deny rules not enforcing — see issue #64770 Initially the deny rules appeared broken, but the actual cause was that the repo-level settings file wasn't being loaded at all.
• The workspace-level .claude/settings.json does load correctly. The issue is specific to nested repo-level settings files.
• A multi-repo workspace setup (one parent directory containing several project folders, each with their own .claude/settings.json) is a common pattern — this makes repo-level permission scoping completely non-functional in that setup.