macOS Ghostty loses folder access during Claude sessions despite Full Disk Access

[Ahmeth4n]

Issue Description

When using Claude Code inside Ghostty on macOS, filesystem access to project directories eventually stops working even though Ghostty has Full Disk Access enabled.

Initially, Claude can access files and directories without any issues. After some time, however, Claude starts reporting that it cannot access directories that were previously accessible. The issue can be temporarily resolved by going to System Settings -> Privacy & Security -> Full Disk Access and disabling/re-enabling Ghostty's Full Disk Access permission. After doing so, access is restored for a while, but the problem eventually returns.

Because toggling Full Disk Access temporarily fixes the issue, it seems that Ghostty may be losing access to permissions that were previously granted.

Expected Behavior

Ghostty should retain Full Disk Access permissions for the duration of the session, and applications running inside Ghostty (such as Claude Code) should continue to have access to directories that were previously accessible.

Re-enabling Full Disk Access should not be necessary.

Actual Behavior

After using Claude Code for some time, filesystem access is lost and Claude can no longer access directories that were previously available.

Disabling and re-enabling Ghostty's Full Disk Access permission in macOS temporarily restores access, but the issue eventually reoccurs.

Reproduction Steps

1. Grant Full Disk Access to Ghostty in macOS System Settings.
2. Open Ghostty.
3. Start a Claude Code session in a project directory.
4. Use Claude normally for some time.
5. Observe that Claude eventually loses access to directories that were previously accessible.
6. Go to System Settings → Privacy & Security → Full Disk Access.
7. Disable and re-enable Ghostty's Full Disk Access permission.
8. Observe that access is restored temporarily.
9. Continue using Claude until the issue reoccurs.

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1
Build 15212

OS Version Information

macOS Tahoe 26.3

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

focus-follows-mouse=true
background=black
font-family=IBM Plex Mono
keybind = super+h=goto_split:left
keybind = super+j=goto_split:bottom
keybind = super+k=goto_split:top
keybind = super+l=goto_split:right
window-padding-color=extend
window-padding-x = 2
split-divider-color=#FFA500
keybind = super+up=increase_font_size:1
keybind = super+down=decrease_font_size:1

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[bo2themax]

Did you try to access the file using ls/cat outside of Claude when it happens? I use Claude a lot, never encounter this.

[Ahmeth4n]

same, all commands return permission denied. But when I use the default macOS Terminal, everything works normally.

also looks like I'm not the only one experiencing this issue; https://www.reddit.com/r/Ghostty/comments/1tvuxx0/terminal_keeps_losing_access_to_my_folder_despite/

[JohannesMessner]

Experiencing the same with Codex (but haven't observed it with Claude Code yet)

[codeshaunted]

this happens to me randomly as well, seems like its more common when im running many claude session in parallel, but i've had it happen with just a single session

[bettep-dev]

For what it's worth, I am experiencing this exact same issue in the standard macO(Tahoe) Terminal app as well.
​From what I've investigated, the root cause seems to be that Claude Code loses its filesystem permissions during an automatic update. Because of this, I suspect it might be a macOS-level permission handling issue rather than a terminal-specific bug.
​Super frustrating!

[arnold117]

Same here, I use both Claude Code and Codex.

[ohamma8253]

This is not a Ghostty bug. Same symptom reproduces in Terminal.app and iTerm2 — Ghostty is only the responsible app that macOS attributes the TCC grant to, so it's the one that has to be restarted to recover.

Mechanism, as far as it's understood so far:

• The refusal is a kernel Sandbox System Policy deny, not a TCC deny — nothing is ever logged under the com.apple.TCC subsystem, and the grants in TCC.db read authValue=2 (allowed) the entire time the break is active. So it isn't permission loss; it's permission not being applied.
• The observable gate appears to be the com.apple.macl xattr on the protected folder root (~/Documents etc.) disappearing — present when working, absent when broken.
• The trigger correlates with jetsam mass-sweeps under memory pressure, not with anything the terminal does. It can fire with tccd alive and never restarted.
• Toggling Full Disk Access off/on works for the same reason a terminal restart works: it re-establishes attribution. FDA being on doesn't prevent it — every incident I logged had FDA on.

The upstream thread with kernel-log timelines, counterfactuals, and the per-folder (Desktop vs Documents vs Downloads) asymmetry: anthropics/claude-code#58952 — I just posted a data dump there.

Practical notes for anyone hitting this:

• Recovery: Cmd+Q the terminal app and relaunch. Restarting only the CLI inside the same terminal does not work (verified — a freshly spawned process in the old tree is still denied).
• Immunity: keep active working trees outside ~/Documents / ~/Desktop / ~/Downloads. Non-protected paths need no grant, so they're unaffected regardless.
• Frequency scales with memory pressure. Cutting resident memory (fewer long-lived heavy processes, occasional reboot) took me from recurring breaks to zero in the last week.

Worth noting for triage: it isn't Claude-specific either. Claude Code just happens to be a long-running process doing sustained file I/O inside protected folders, which is what makes the break visible.

[behruznassre]

Adding a confirmation with a data point that I think extends the scope of this report: it is not limited to the protected home folders.

On my Mac Studio this took out four external APFS volumes simultaneously (/Volumes/Data1, /Volumes/Data2, /Volumes/Data3, /Volumes/Media), read and write, in Ghostty only. None of those is a TCC-protected home folder. That matters because it falsifies the "keep your projects outside ~/Documents/~/Desktop/~/Downloads" workaround suggested earlier in this thread — all my work is on /Volumes/Data3 precisely because it is not a protected location, and it broke anyway.

It also means the com.apple.macl xattr explanation, which is specific to protected home folders, may not be the whole mechanism — or at least isn't the mechanism here. I can't speak to whether a second path leads to the same kernel state.

Environment

• Ghostty 1.3.1 (build 15212) — same build as the original report
• macOS 26.5.2 (25F84), Apple silicon (Mac Studio) — a newer point release than the 26.3 reported above, so not fixed in 26.5.2
• Ghostty process had been running 14 days (launched at boot)
• Occurred twice: 2026-06-27 and 2026-08-03

Evidence that it is not TCC

I captured this while the failure was live, before recovering. Everything below is from the same incident window:

Check	Result
ls /Volumes/Data3 in Ghostty	Operation not permitted, exit=1
stat /Volumes/Data3 in Ghostty	exit=0 — succeeds at the same instant
Volume state	mounted normally (/dev/disk11s1, apfs), no unmount/remount events in the log
kTCCServiceSystemPolicyAllFiles / com.mitchellh.ghostty	auth_value=2 (Allow)
kTCCServiceSystemPolicyRemovableVolumes / com.mitchellh.ghostty	auth_value=2 (Allow)
tccd decisions for Ghostty during the incident	AUTHREQ_RESULT ... authValue=2 — allowed
TCC requests generated by the failing ls	zero
Kernel Sandbox: ... deny(...) lines for the failing ls	zero

So the grant is present, tccd affirmatively allows it when asked, and the denial happens with no TCC request and no sandbox deny record — consistent with the "permission not being applied rather than lost" reading already in this thread.

Notably, Full Disk Access had been granted to Ghostty on 2026-06-28, the day after the first occurrence, specifically as an attempted fix. It did not prevent the 2026-08-03 recurrence — FDA was granted and honored throughout. Anyone landing here from a search should know that toggling FDA is masking, not fixing.

Memory-pressure correlation

Consistent with the jetsam theory upthread. At the moment of failure:

• uptime 14 days
• swap 93% exhausted — 10,471 MB used of 11,264 MB
• free system-wide memory still 43%, so this was swap/compressor exhaustion rather than RAM starvation

I run several concurrent Claude Code and Codex CLI sessions in Ghostty tabs, which is a heavy long-lived workload — same usage pattern as the original report.

Recovery

Confirming what others found:

• A new Ghostty window/tab is not sufficient — a freshly spawned shell under the same app process is still denied (exit=1).
• Quitting Ghostty (Cmd-Q, full app exit) and relaunching restores access immediately — ls /Volumes/Data3 → exit=0. No reboot, no TCC toggle, no logout.

For anyone else hitting this mid-session: nothing durable is lost by restarting the app. Claude Code transcripts live on the internal disk under ~/.claude/projects/<slug>/<uuid>.jsonl (resume with claude --resume) and Codex rollouts under ~/.codex/sessions/YYYY/MM/DD/ (codex resume). The in-flight sessions are already unable to read or write the volume anyway.

One caveat on the "reproduces in other terminals" claim

I want to be precise, because I initially drew the wrong conclusion myself. During the incident a freshly launched iTerm2 read all four volumes fine while Ghostty was denied. That is not evidence that iTerm2 is immune — it had been running for minutes, not 14 days, so it had no opportunity to accumulate the state. It only establishes that the fault is per-process rather than system-wide. I have no long-running-iTerm2 data point either way.