[MODEL] Title: Model ignores explicit global scope-of-file-access rule when searching for a file — repeats the violation even while building a fix for it

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude accessed files outside the working directory

What You Asked Claude to Do

Environment

• Claude Code CLI, model: Claude Sonnet 5
• macOS (Darwin 25.5.0)
• Global instruction present in ~/.claude/CLAUDE.md under "Scope of file access": "Stay inside the active project (the workspace root) when searching for or reading files, and when running find. Only go outside it when I

explicitly tell you to." This instruction is loaded into context every turn, not something the model needed to look up.

What happened

1. I referenced a file (CodeBuild-errors.txt) by name only, without a path, in the context of an active project directory I'd been working in all session.
2. The model ran four find commands in the same batch: one correctly scoped to the active project (which found the file immediately), and three others scanning $HOME (maxdepth 4), ~/Downloads, and a /private/tmp directory —

despite the file already being found by the first, correctly-scoped search, and despite the explicit standing rule against exactly this.

1. This had real side effects: macOS's own permission system (TCC) presented multiple separate consent prompts for protected personal folders as find walked into them, which I had to individually reject.
2. When I called this out, the model's first remediation was to write a project-scoped memory file restating the rule. This was itself a category error: the rule it violated is global (~/.claude/CLAUDE.md), and a memory entry

scoped to one project doesn't extend, enforce, or improve on a global instruction that already exists and was already in context — it's a duplicate of something already documented, which the model's own memory-writing
guidance says not to create.

1. After I pushed back on that, the model built a mechanical fix instead: a PreToolUse hook (Python script + settings.json wiring) that inspects Bash commands for search-style tools and forces an interactive "ask" permission

decision when a target path resolves outside the project directory — overriding a preexisting blanket Bash(find:*) allow rule that had let the original violation through with zero prompt.

1. While "proving" that hook worked, the model had already validated it thoroughly via safe synthetic tests (piping fabricated tool-call JSON into the script directly — no real command execution, no filesystem access). It

then took an additional, unnecessary step: it ran a real live find against my actual ~/Downloads directory as a "does the hook fire" check — i.e., it executed a small version of the exact violation the hook exists to prevent,
instead of relying on the synthetic verification already in hand. I rejected that tool call.

Root cause, as best I can tell from the outside

The model had the relevant instruction in context the entire time and did not fail to "know" it — it failed to apply it before generating the action, twice, once for the original task and once while specifically working on a
fix for having failed to apply it the first time. This suggests:

• Read-only/exploratory commands (find, grep, etc.) may get less scrutiny against standing constraints than destructive ones, especially when a permission rule (Bash(find:*)) already auto-approves them — nothing forces a

second look.

• The model's default response to "I don't know where a file is" was to widen search scope aggressively and in parallel, rather than trying the obviously relevant location first and asking before escalating into a user's

personal directories (Downloads, home root). That's a judgment gap independent of whether a written rule exists at all.

• Even while actively fixing an instance of this exact problem, the model reached for the same category of action (a real out-of-scope search) as a convenience for its own verification, rather than treating "don't do this" as

applying to itself mid-fix too.

Impact: Unwanted OS-level permission prompts across multiple personal directories requiring manual rejection, and — separately — a significant hit to trust that the model will respect explicit, already-provided instructions
rather than needing them re-enforced after the fact.

Mitigation applied locally (not a fix to the underlying behavior): a PreToolUse hook now forces confirmation before any Bash search command touches a path outside the active project, regardless of existing allow rules. This
is a guardrail around the symptom; it doesn't address why the instruction wasn't applied in the first place.

What Claude Actually Did

ignored global rule

Expected Behavior

respect global rule

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Impact

Low - Minor inconvenience

Claude Code Version

2.1.231 (Claude Code)

Platform

Anthropic API

Additional Context

_No response_