Crash (unhandled EPERM, minified stack) when launching/resuming in a TCC- or iCloud-access-revoked directory — ENOENT cases are handled gracefully, EPERM is not

Description

When Claude Code starts in a directory where macOS has revoked the app's file
access (e.g. an iCloud-synced ~/Desktop project after a TCC permission
change), it crashes with an internal error instead of showing an actionable
message. The failure mode is nasty because the directory looks fine to a
launcher: stat() succeeds and chdir() succeeds — only actual reads fail,
with EPERM. So any wrapper/terminal happily spawns claude in that cwd, and
claude then dies on its first synchronous read.

In interactive mode the user sees a raw minified stack trace referencing
createElement (Ink/React render), fileContents, readFileSync, and
/$bunfs/root/claude/... bundle paths. In -p mode the same failure surfaces
as a one-line error: An internal error occurred (EPERM).

By contrast, the missing-path cases are already handled gracefully:

• unknown session id → No conversation found with session ID: <id> (clean exit)
• nonexistent cwd → the process can't even start there (launcher's problem)

Only the "directory exists but reads are forbidden" case escapes as an
internal error / raw stack.

Reproduction (macOS, claude 2.1.217)

1. Have a project directory whose read access macOS has revoked for your

terminal (an iCloud Drive folder after revoking the app's
"Files and Folders" / Full Disk Access permission reproduces this;
the state looks like):

``
$ cd /Users/<user>/Desktop/<project> # succeeds (traversal allowed)
$ ls # fails
ls: .: Operation not permitted
``

1. Run any of:

```
$ claude -p "hi"
error: An internal error occurred (EPERM) # exit 1

$ claude -p --resume <valid-session-id-for-this-cwd> "hi"
error: An internal error occurred (EPERM) # exit 1

$ claude --resume <valid-session-id-for-this-cwd>
# interactive: minified stack trace (createElement / fileContents /
# readFileSync frames, /$bunfs/root/claude/... paths), then exit
```

Expected

A clear, actionable error, analogous to the missing-id message — e.g.:

Claude Code can't read this directory (macOS denied access — check iCloud / Privacy & Security → Files and Folders). Move the project or grant access, then retry.

Notes

• The EPERM likely first surfaces in startup/context reads (project

CLAUDE.md, settings, directory listing) and in the resume path's
file re-reads while re-rendering transcript messages; wherever the first
unguarded readFileSync/readdirSync happens, only ENOENT seems to be
anticipated.

• Real-world trigger: iCloud-synced Desktop/Documents folders. macOS revokes

access without the user doing anything to the folder itself; users then
"resume" old sessions in a folder that stats fine and hit this crash.

• Version: reproduced on 2.1.217 (native/bun binary, macOS 15 / Darwin 25).

A user report with the same signature came from a wrapper launching
claude --dangerously-skip-permissions --resume <id> in such a folder.