[BUG] Unacceptable File Access

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?

Read-only shell commands bypass the working-directory boundary — silent filesystem enumeration outside the project with no prompt

BODY (paste everything below into the description box):

Summary

The permissions documentation (code.claude.com/docs/en/permissions, "Working directories") states: "By default, Claude has access to files in the directory where you launched it," with access extended only via --add-dir, /add-dir, or additionalDirectories.

However, read-only shell commands are auto-approved with no path check — and crucially, this means the model itself can decide to enumerate directories anywhere on the machine (the user's Desktop, personal folders, other drives) without the user asking it to, without any permission prompt, and without any allow rule. The returned filenames then become part of the conversation transcript (i.e., they are transmitted off the machine) with the user never having been asked.

What actually happened (the incident)

I did NOT ask Claude to search outside my project. During a session working entirely inside my project folder, I asked a question scoped to that work — essentially "can you think of any other file types we haven't covered?" The model, on its own initiative, ran directory searches across my Desktop, Downloads, and Documents folders. No prompt was shown (read-only auto-approval). I only discovered it afterward, when it referenced a folder on my Desktop and I asked how it knew that folder existed.

That distinction matters: if a user explicitly says "search my Desktop," silent execution is fine — the access is user-intended. The problem is that when the MODEL originates the out-of-bounds access from an ambiguous instruction, there is no harness backstop at all. The documented working-directory boundary is enforced against nothing.

Steps to reproduce

The mechanism is trivially demonstrable: in a default-mode session launched in a project directory, ANY read-only directory-listing command targeting a path outside the project (Get-ChildItem C:\Users\<user>\Desktop, ls on another drive, etc.) is auto-approved and executes with no prompt. No allow rule, no --add-dir, no user consent.

In my incident, the model generated those commands entirely on its own: I asked "can you think of any other file types we haven't covered?" — a question with no location in it, asked in the context of work inside the project — and the model chose to sweep Desktop, Downloads, and Documents as its own idea of being thorough. Because model-initiated behavior isn't deterministic, the reliable repro is the mechanism above; the incident shows the mechanism gets exercised unprompted in real use.

Observed: the command executes immediately with no permission prompt — read-only auto-approval applies regardless of the target path or of who (user vs. model) originated the idea. Results — real filenames from personal folders — enter the conversation.

Expected: filesystem access outside the working directory and additionalDirectories — including reads and directory listings — should require explicit user approval, consistent with the documented working-directory scope. Especially so when the access is model-initiated rather than user-requested.

Suggested fix

• Read-only command auto-approval should respect the same directory boundary as everything else: auto-approve only when every path argument resolves inside the working directory / additional directories; prompt otherwise.
• At minimum, make this behavior prominent in the permissions docs and offer a setting to enforce strict directory scoping for reads.

Users can currently defend against this only with Read/Edit deny rules — which requires them to already know the gap exists, enumerate their own personal folders, and know the // absolute-path rule syntax. Almost no one will do this preemptively, because the product's own framing ("Claude works in the folder you open it in") tells them they don't need to.

Environment

• Claude Code CLI v2.1.198
• Windows 11, PowerShell tool (behavior is presumably identical for Bash read-only commands on other platforms)
• Default permission mode, project-scoped launch