[SECURITY] Project trust persists after directory deletion, auto-applies to new projects at same path

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

Project trust and permissions stored in ~/.claude.json are keyed solely by directory path. When a trusted directory is deleted and a new, unrelated project is created at the same path, Claude Code silently grants the new project full permissions without prompting the user. This bypasses the intended trust verification workflow.

Security Impact

Severity: Medium-High

Claude Code gains read, write, and execute permissions in trusted directories. The current implementation assumes a directory path is a stable identifier for a trusted project, but this assumption fails in several scenarios:

1. Reused paths: User deletes a project, creates an entirely different one at the same path (or renames a project directory to one previously used)—it silently inherits full read/write/execute permissions without any prompt
2. Shared machines / multi-user systems: Another user creates a project at a path the original user previously trusted
3. Temporary directories: If a user ever trusted something in /tmp/project or similar, any future project at that path inherits trust
4. Potential malicious exploitation: An attacker with knowledge of a user's previously trusted paths could create a project at that location to gain automatic Claude Code access

What Should Happen?

Expected Behavior

Claude Code should prompt for trust verification when:

• A previously trusted directory has been deleted and recreated
• The contents of a trusted directory have fundamentally changed (e.g., different git repository, no overlapping files)

Suggested Mitigations

Any of these would improve the current situation:

1. Project identity verification: Tie trust to path + a project identifier (e.g., hash of .git/config, a generated .claude/project-id file, or similar)
2. Directory existence check: On startup, prune trust entries for paths that no longer exist, or flag them for re-verification when they reappear
3. Recreated directory detection: Track directory inode or creation timestamp; prompt if these change
4. User warning: At minimum, warn when a trusted path appears to be a different project than when it was originally trusted

Additional Context

The current workaround is to manually edit ~/.claude.json and remove the project entry, but this requires users to:

1. Know this file exists and controls trust
2. Remember to do this every time they delete a project
3. Correctly identify and remove the relevant JSON entries

This is not a reasonable expectation for most users and leaves a silent security gap for those unaware of this behavior.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. Create a new project directory: mkdir ~/test-project
2. Run claude in that directory
3. When prompted "Do you trust the files in this folder?", select "Yes, proceed"
4. Exit Claude Code
5. Delete the directory: rm -rf ~/test-project
6. Create a new, unrelated project at the same path: mkdir ~/test-project
7. Run claude in that directory
8. Observe: No trust prompt appears; Claude Code has full permissions

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.9

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

IntelliJ IDEA terminal

Additional Information

_No response_