claude-code - 💡(How to fix) Fix Intermittent "Working directory was deleted" + EPERM on file ops when project lives under ~/Documents/Claude/* (macOS Tahoe)

Version: Claude Code 2.1.145 (build SHA daa4c3755d45ab0cf97bb41db8c03bd2dfd2ff5f) Platform: macOS 26.x (Tahoe), Darwin 25.4.0, arm64 Launch context: Claude Code CLI launched from Claude Desktop app (/Applications/Claude.app)

Symptoms

During a long session with a project at ~/Documents/Claude/<project-name>:

1. After ~5–10 successful Bash/Edit calls, subsequent Bash calls return: Working directory "/Users/<user>/Documents/Claude/<project-name>" was deleted; shell cwd recovered to "/Users/<user>". Re-issue your command (it will run from the recovered directory). The directory exists and has normal permissions throughout.
2. After the cwd reset, Read and Edit tools return EPERM: operation not permitted on absolute paths inside the project. dd if=<path> of=/dev/null from a fresh Bash call also returns Operation not permitted, but stat <path> succeeds — indicating the Seatbelt profile is missing file-read-data for the project path even though metadata access is allowed.
3. Workaround: bundling everything inside cd <project> && <work> in a single Bash call works reliably. The failure is between invocations.

What I confirmed by inspecting the binary

• claude.exe contains Seatbelt profile syntax and sandbox-exec invocation logic. Per-call useSandbox flag.
• The "was deleted" message comes from a realpath(recorded_cwd) call inside claude.exe that throws, then walks a fallback list (origCwd, homedir, project root) and surfaces the recovery message when the recovered dir isn't the first in the fallback list.
• cwd is persisted between Bash invocations via pwd -P >| /tmp/claude-XXXX-cwd appended to each shell command.

Speculative root cause

The project path contains Claude as a segment (~/Documents/Claude/<project-name>), and the CLI's parent process is Claude.app. macOS Tahoe (26.x) further tightened the App Management / TCC restrictions that arrived in Sequoia. Possible that the kernel is intermittently returning EPERM on realpath / open from claude.exe to paths whose parent directory shares a name with the parent app's display name, treating it as suspicious app-self-modification. Could not confirm without TCC log access (log stream --predicate 'subsystem == "com.apple.TCC"').

Repro suggestion

Place a project at ~/Documents/Claude/<anything>/ on macOS Tahoe, launch Claude Code from Claude.app, perform 10+ mixed Bash + Read/Edit calls in one session. Observe intermittent failures. Worth comparing against a project at ~/Documents/<other-name>/<project>/ to isolate whether the Claude/ path segment is load-bearing.