[BUG] No permission prompt before reading/searching files OUTSIDE the working 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?

Summary

When a task could not be satisfied within the working directory, Claude Code
searched the parent directory (one level above the working directory)
without showing any permission prompt.

The concern here is NOT that Claude has the capability to reach outside the
working directory. The concern is that crossing the working-directory
boundary did not trigger an approval prompt, even though the startup trust
dialog leads users to believe the working directory is the access boundary.

What Should Happen?

Expected behavior

Before any read/search/glob/grep touches a path outside the working
directory, Claude Code should show an explicit permission prompt
("Allow access to <path> outside the working directory?"), so the user can
approve or deny it.

This matches the mental model created by the startup trust dialog:
"Claude can work inside this folder; anything above it is off-limits unless
I say otherwise."

Actual behavior

The parent directory was scanned with no permission prompt at all.

Error Messages/Logs

Steps to Reproduce

Environment

• OS: Windows 11
• Shell: PowerShell
• Working directory: C:\Projects\project_directory\working_directory
• Parent that got accessed: C:\Projects\project_directory (one level up)
• Claude Code version: <Version: 2.1.168>

What happened (reproduction)

1. I asked Claude whether it could open / edit Excel files.
2. To test this, Claude attempted to actually open an Excel file

(checking whether an installable helper, e.g. a pip package, was usable).

1. There were no Excel files under the working directory.
2. Claude then **scanned the parent directory (one level up) to look for

Excel files — without asking for my approval first.**

My guess

The working directory was operated with exactly the same name as the project
directory (one level up). Because of this, Claude Code may have concluded
that it was safe to look at the parent directory.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Version: 2.1.168

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Why this matters

The folder above the working directory may contain sensitive material the
user never intended to expose — password files, company-confidential
documents, other clients' projects, etc. Silently crossing that boundary
(without an approval step) is a privacy/security risk and a potential
liability concern, because it violates the boundary users reasonably infer
from the trust dialog.

Suggested improvement

• Treat the working-directory boundary as an explicit permission boundary:

require an approval prompt before reading/searching/editing any path
outside it (opt-in, per-path or per-session).

• Optionally make this configurable, but the default should err toward

prompting before leaving the working directory.

• As a workaround today, a PreToolUse hook can deny out-of-directory

access — but this should not require users to discover and build it
themselves.

Workaround I implemented

A PreToolUse hook (PowerShell) that denies Read/Edit/Write/Glob/Grep/
NotebookEdit for any path resolving outside the working directory
(and ~/.claude). This confirms the boundary can be enforced — it just
isn't enforced (or prompted) by default.