[BUG] Claude creating file limit filesystem bug on long or many sessions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28896
2. https://github.com/anthropics/claude-code/issues/21701
3. https://github.com/anthropics/claude-code/issues/28046

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

It is NOT a duplicate.

Have to add, codex had the only solution that worked so far. After this incident, running these commands:

tccutil reset SystemPolicyDocumentsFolder com.apple.Terminal
tccutil reset SystemPolicyDesktopFolder com.apple.Terminal
tccutil reset SystemPolicyDownloadsFolder com.apple.Terminal

Still, it shouldn't happen anyway.

Root Cause: File Descriptor Leak + macOS TCC Permission Revocation

This is a file descriptor (FD) exhaustion issue that triggers macOS TCC permission revocation as a side effect. Here's the chain:

The Sequence:

1. Claude Code (and its Node.js subprocess) opens file descriptors over time (sockets, file handles, pipes)
2. FDs are not being properly closed — they accumulate across sessions
3. When FDs approach the limit (10,240 soft, higher hard), new open() syscalls fail
4. macOS interprets the failed filesystem operations as a permission issue
5. TCC (Transparency, Consent & Control) revokes Terminal.app's folder access
6. Even after Claude exits, Terminal.app has lost its grants — ls . fails

Evidence:

• Operation not permitted (EPERM) — this is TCC, not EACCES
• tccutil reset fixing it confirms TCC revocation
• Issue appears after "hours or a day" — consistent with slow FD leak
• Works in iTerm (different bundle ID, separate TCC grants)
• Reboot clears it (restarts TCC daemon + closes all FDs)

Diagnosis Commands:

# Check current FD count for Claude processes
lsof -c claude 2>/dev/null | wc -l

# Check per-process FD limits
launchctl limit maxfiles

# Monitor FD growth over time (run while using Claude)
while true; do
  count=$(lsof -c claude 2>/dev/null | wc -l | tr -d ' ')
  echo "$(date +%H:%M:%S) FDs: $count"
  sleep 60
done

Immediate Fix (before reboot):

# Reset TCC for Terminal.app
tccutil reset All com.apple.Terminal

# Or more targeted:
tccutil reset SystemPolicyDocumentsFolder com.apple.Terminal
tccutil reset SystemPolicyDesktopFolder com.apple.Terminal
tccutil reset SystemPolicyDownloadsFolder com.apple.Terminal

# Then reopen Terminal and grant access when prompted

Preventive (raises FD limits):

# Add to ~/.zshrc
ulimit -n 65536

# Or system-wide (persistent):
sudo sh -c 'echo "limit maxfiles 524288 524288" >> /etc/launchd.conf'

Real Fix (needs Claude Code side):

The Node.js process needs proper FD hygiene — likely candidates:

• child_process.spawn() without stdio: 'ignore' on unused streams
• HTTP connections not using keepAlive pooling properly
• File watchers (fs.watch()) not being disposed

---
RevolutionAI — macOS sandbox debugging

I would like to chime in and say I'm seeing the same here when using Cowork. It seems like the file descriptors are leaking in com.apple.Virtualization.VirtualMachine which I believe is used by Claude Code and Cowork. I initially thought it was caused by Docker, but it seems to be isolated to Claude when it's working on files.

One thing I did notice, was that when running the latest version of Docker and VirtioFS, I would also see the file descriptors

I'm also seeing that icons will start to become corrupted when file descriptors hit around 230.000 as well as TCC errors in the logs. I tried to reset TCC a few times and it seems to work, but it will go bad again when running Claude for a while.

echo "=== Total FDs: $(sudo lsof -n 2>/dev/null | wc -l | tr -d ' ') ===" && \
sudo lsof -n 2>/dev/null | awk '{print $2}' | sort | uniq -c | sort -rn | head -15 | while read count pid; do
  name=$(ps -p "$pid" -o comm= 2>/dev/null | sed 's|.*/||' || echo "dead")
  printf "%6d  %s\n" "$count" "$name"
done
=== Total FDs: 262241 ===
227640  com.apple.Virtualization.VirtualMachine

Model: Sonnet 4.6
Version: 1.1.7714 (Claude desktop app for Mac) and 2.1.25 (claude code/CLI)

Quick chime-in: Using claude code v2.1.92 - ran into this issue today.
resetting SystemPolicyDocumentsFolder approval seemed to fix the issue at the moment, but as @xXMrNidaXx pointed out, should not have happened in the first place.

Similar state in claude code v2.1.107 on macOS 26.3.1 - ran into this issue multiple times over the course of last 2 weeks.

Also, the fix mentioned in the above comments does not work when working with Warp terminal. Were they given assuming that claude was started in the default terminal of the macOS?

warp 遇到了

For Warp, the Warp bundle ID is dev.warp.Warp-Stable (you can check with osascript -e 'id of app "Warp"' or mdls -name kMDItemCFBundleIdentifier /Applications/Warp.app)

So it becomes:

# Reset TCC for dev.warp.Warp-Stable
tccutil reset All dev.warp.Warp-Stable

# Or targeted:
tccutil reset SystemPolicyDocumentsFolder dev.warp.Warp-Stable
tccutil reset SystemPolicyDesktopFolder    dev.warp.Warp-Stable
tccutil reset SystemPolicyDownloadsFolder  dev.warp.Warp-Stable

Latest error pattern looks like that:

2026-05-09 18:28:18.096 open[41891:18074376] CFURLCopyResourcePropertyForKey failed because it was passed a URL which has no scheme
2026-05-09 18:28:18.096 open[41891:18074376] CFURLCopyResourcePropertyForKey failed because it was passed a URL which has no scheme
2026-05-09 18:28:18.096 open[41891:18074376] CFURLCopyResourcePropertyForKey failed because it was passed a URL which has no scheme
No application knows how to open URL ./ (Error Domain=NSOSStatusErrorDomain Code=-10814 "kLSApplicationNotFoundErr: E.g. no application claims the file" UserInfo={_LSLine=1973, _LSFunction=runEvaluator, _LSFile=LSBindingEvaluator.mm, _LSErrorMessage=kLSApplicationNotFoundErr}).

Same the same command can fix it for a specific amount of time, till it happens again.

I have the same error pattern. It is extremely annoying

2.1.145 (Claude Code) still has the issue, and I had to reboot macOS.

Adding a new severity tier to this thread: on macOS this leak now correlates with kernel panics, not just user-visible errors. Same root cause, much worse blast radius when multiple Claude Code instances run concurrently.

Environment

• macOS 26.5 (25F71), Darwin 25.5.0 (xnu-12377.121.6~2), Apple Silicon, 64 GB RAM
• Claude Code 2.1.144 (CLI, multiple concurrent instances)

What happened — 4 reboots in 1 week, 2 distinct failure modes, 1 root cause

Mode A — kernel panic (×3) on 5/14, 5/16, 5/21 20:35:

panic(...): initproc exited -- exit reason namespace 2 subcode 0xa

launchd (PID 1) hits a libSystem-internal assert and exits → kernel panic → auto-restart. Survived a macOS version upgrade (26.2 → 26.5), which rules out OS-side bugs as the root cause.

Mode B — system-wide ENFILE freeze (×1) on 5/21 23:26 — the smoking gun:

Error: ENFILE: file table overflow, mkdir '/private/tmp/claude-.../tasks'

That's kern.maxfiles=491520 exhausted, surfaced by Claude Code's own Bash tool. Full system became unresponsive; only recovery was long-pressing the power button (ResetCounter-*.diag shows Boot faults: btn_seq_reset).

The fd evidence (the part I think is new)

macOS JetsamEvent-*.ips files record per-process fd counts at memory-pressure events. From 7 hours before the 23:26 freeze:

51200 fds  rpages=29626  pid=27061  2.1.144   ← Claude Code
51200 fds  rpages=28282  pid=51172  2.1.144   ← Claude Code
51200 fds  rpages= 3985  pid=99001  2.1.144   ← Claude Code  (fd/page = 12.8:1)
25600 fds  rpages=41312  pid=92811  2.1.144   ← Claude Code
─────────────────────────────────────────────
                179,200 fds across 4 Claude Code instances
                = 36.4% of system kern.maxfiles=491520

For scale, every other process at the same moment:

 1600 fds  Feishu        (large IM app, baseline-heavy)
 1200 fds  node
  800 fds  Lark / Chrome / OrbStack Helper
  400 fds  BiomeAgent / mDNSResponder / mds_stores / VSCode / system services

Normal apps are in the 100s. Claude Code single-process is at 51200, ~50–100× normal. The fd:rpage ratio on pid 99001 (12.8:1 vs a normal ~0.05:1) is the structural fingerprint of fd leak — the process holds 51200 kernel fd table entries while occupying only ~60 MB of physical memory.

Across a 12 h window the same PID 92811 held a steady 25600 fds at both 04:06 and 16:34 — fds are not being released over the life of the process, not just leaked at session end.

Why multi-instance is the cliff

A single long-running Claude Code that hits its RLIMIT_NOFILE only kills itself (#47909-style symptoms). Multiple concurrent instances each grow toward their per-process ceiling and collectively pressure kern.maxfiles. Once kern.num_files is close to the system cap:

• launchd's per-second open/dup/socket/kqueue workload starts hitting allocation failures
• a libSystem assert site catches the failure → __abort_with_payload → initproc exited subcode 0xa → kernel panic (Mode A)
• if the system fully exhausts the table first, every process's open(2) returns ENFILE and the machine freezes hard (Mode B)

Both modes are downstream of the same Claude Code fd leak. Heavy users who run multiple agents/sessions in parallel will hit Mode B before Mode A.

Suggested fix priorities

1. The leak itself. A pid-99001-shaped process (3985 pages, 51200 fds) is diagnostic. Almost certainly subprocess pipes / kqueue knotes / PTY masters not closed across Bash tool invocations (see also #57580 for the PTY-specific manifestation).
2. Hard cap at the harness level. Even before the underlying leak is fixed, refusing to issue tool calls when the process is above (say) 5000 fds would prevent the cliff.
3. Surface the right diagnosis. When fd allocation fails the current paths emit ENOENT, "directory no longer exists", or generic spawn errors. A single getrlimit + getdtablesize check at error time would let the tool surface "fd exhaustion detected" instead.

Diagnostic for anyone hitting this

# Per-claude-process fd counts (live)
for pid in $(pgrep -f claude); do
  n=$(lsof -p $pid 2>/dev/null | wc -l | tr -d ' ')
  echo "pid=$pid fds=$n"
done | sort -t= -k3 -rn

# System-level fd table headroom
sysctl kern.num_files kern.maxfiles

# After-the-fact forensics (if macOS captured a JetsamEvent)
jq -r '.processes | sort_by(-.fds) | .[0:25] | .[] | "\(.fds) fds  pid=\(.pid)  \(.name)"' \
  /Library/Logs/DiagnosticReports/JetsamEvent-*.ips

Single Claude Code process > 5000 fds on a long session = on the leak path.

Request
This issue is blocking adoption for developers working with large monorepos. Since #51933 was previously closed just because the lack of activity, if it was really resolved this appears to be a regression introduced between 2.1.126 and 2.1.143.

Could the team:

Investigate what changed between these versions related to file handle management?
Consider re-opening #51933 or tracking this as a separate regression?
Add regression tests for large monorepo scenarios to prevent this from recurring?
Happy to provide additional diagnostics if helpful.

Reproduction Confirmed - Appears to be Regression from #51933

We're experiencing what appears to be a regression of the file descriptor leak issue reported in #51933, which was previously marked as resolved.

Environment

• Affected versions: 2.1.143, 2.1.145
• Last working version: 2.1.126
• Repository type: Large Android/Kotlin monorepo (multi-module)
• Platform: macOS
• Symptom frequency: Occurs within 10-30 minutes of usage

Observed Behavior

The file descriptor leak manifests in several ways:

1. System-level instability: System freezes requiring hard reboot
2. File system corruption: Git index files and IDE metadata become corrupted after crash
3. Directory access errors: ls: .: Operation not permitted after Claude sessions
4. Persistent damage: Even after closing Claude, the corruption remains until reboot

Impact

• Multiple developers affected when working with large monorepos
• Corrupted git metadata requires re-cloning repositories
• IDE index rebuilds taking 1+ hours after recovery
• Some cases requiring machine reimaging

Reproduction Pattern

The issue appears to be triggered by:

• Working in large monorepos with many modules
• Extended sessions or using /plan mode
• The behavior seems random but consistently occurs within the first 10-30 minutes

Current Workaround

Downgrading to version 2.1.126 resolves the issue completely:

# 1. Install target version
curl -fsSL https://claude.ai/install.sh | bash -s 2.1.126

# 2. Remove higher versions to prevent auto-update
rm -rf ~/.local/share/claude/versions/2.1.143
rm -rf ~/.local/share/claude/versions/2.1.145

# 3. Verify symlink points to 2.1.126
ls -la ~/.local/bin/claude

issue persists on macOS, just got this for the first time, never happened before, probably related to the enw update

macOS上问题依然存在，

same problem in macos

To anyone face this issue, I also encountered with ghostty, the issue still there with recent versions, also I suspect my recent SSD failure is related as well, I had an external SSD connected to my Mac mini and it's broken after 2 weeks of heavy agent work within that SSD, maybe not just Claude, all the agents could contribute to the issue

Fix: TCC "Operation not permitted" after multi-agent runs (macOS)

Root Cause

This is not a file-descriptor leak — it's a TCC (Transparency, Consent, and Control) cache corruption issue.

When you run Claude Code with multiple agents for an extended period, ls and other file operations on protected folders (Desktop, Documents, Downloads) start returning Operation not permitted. The cause:

1. Your terminal app (e.g. Ghostty, iTerm2, Terminal.app) has both Full Disk Access (FDA) and per-folder TCC grants (SystemPolicyDesktopFolder, SystemPolicyDocumentsFolder, SystemPolicyDownloadsFolder)
2. Under heavy process load (many spawned subprocesses from multi-agent runs), macOS TCC's in-memory cache for those per-folder grants becomes corrupted
3. The corrupted per-folder check blocks access — even though FDA should allow everything
4. Restarting the terminal or running tccutil reset temporarily fixes it because it flushes the TCC daemon's cache — but the issue recurs

Why tccutil reset SystemPolicyDesktopFolder com.apple.Terminal works (even if you don't use Terminal)

tccutil reset triggers a global TCC daemon cache flush. It doesn't matter that Terminal doesn't have those grants — the flush clears the corrupted cache entry for all apps, including Ghostty/iTerm2.

The Fix (2 layers)

Layer 1: Remove redundant per-folder TCC grants (primary fix)

If your terminal app has Full Disk Access, the per-folder grants are redundant — and they're the thing that gets corrupted. Remove them:

# Reset per-folder grants for your terminal app (replace com.mitchellh.ghostty with your app)
for service in SystemPolicyDesktopFolder SystemPolicyDocumentsFolder SystemPolicyDownloadsFolder; do
    tccutil reset "$service" com.mitchellh.ghostty
done

FDA alone covers all file access. No per-folder grants = nothing to corrupt.

Verify FDA is still active in System Settings → Privacy & Security → Full Disk Access.

Layer 2: LaunchAgent auto-fix safety net (in case it recurs)

A LaunchAgent that runs every 5 minutes, checks the macOS unified log for TCC denial events for your terminal app, and if found, auto-flushes the TCC cache — same effect as running tccutil reset manually.

~/bin/tcc-autofix.sh (replace ghostty / com.mitchellh.ghostty with your terminal app):

#!/bin/bash
# TCC Auto-Fix Agent — detects TCC denials for your terminal app
# and flushes the TCC cache to fix them. Runs every 5 min via LaunchAgent.

LOG_FILE="$HOME/Library/Logs/tcc-autofix.log"

log_msg() { echo "$(date '+%Y-%m-%d %H:%M:%S') [TCC-AutoFix] $*" >> "$LOG_FILE"; }

# Skip if terminal isn't running
if ! pgrep -x ghostty >/dev/null 2>&1; then
    exit 0
fi

# Check TCC logs for denials in the last 5 minutes
# authValue=0 means denied
denial_found=0

tcc_logs=$(/usr/bin/log show --last 5m --predicate 'subsystem == "com.apple.TCC"' --style compact 2>/dev/null)

# Extract msgIDs from SUBJECT lines containing "ghostty"
ghostty_msgids=$(echo "$tcc_logs" | grep "AUTHREQ_SUBJECT" | grep "ghostty" | sed -n 's/.*msgID=\([0-9.]*\).*/\1/p' | sort -u)

if [ -n "$ghostty_msgids" ]; then
    for msgid in $ghostty_msgids; do
        if echo "$tcc_logs" | grep "AUTHREQ_RESULT" | grep "msgID=$msgid" | grep -q "authValue=0"; then
            denial_found=1
            break
        fi
    done
fi

if [ $denial_found -eq 0 ]; then
    exit 0
fi

log_msg "TCC denial detected — flushing TCC cache via Terminal reset"

for service in SystemPolicyDesktopFolder SystemPolicyDocumentsFolder SystemPolicyDownloadsFolder; do
    /usr/bin/tccutil reset "$service" com.apple.Terminal 2>/dev/null
    log_msg "  flushed: $service"
done

log_msg "FIXED: TCC cache flushed — access should be restored"
/usr/bin/osascript -e 'display notification "TCC cache auto-flushed — file access restored" with title "TCC Auto-Fix" subtitle "No action needed"' 2>/dev/null

~/Library/LaunchAgents/com.user.tcc-autofix.plist (replace YOUR_USERNAME):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.tcc-autofix</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/YOUR_USERNAME/bin/tcc-autofix.sh</string>
    </array>
    <key>StartInterval</key>
    <integer>300</integer>
    <key>RunAtLoad</key>
    <true/>
    <key>StandardOutPath</key>
    <string>/Users/YOUR_USERNAME/Library/Logs/tcc-autofix.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/YOUR_USERNAME/Library/Logs/tcc-autofix.log</string>
    <key>ProcessType</key>
    <string>Background</string>
</dict>
</plist>

Install:

chmod +x ~/bin/tcc-autofix.sh
launchctl load ~/Library/LaunchAgents/com.user.tcc-autofix.plist

Notes

• Replace ghostty / com.mitchellh.ghostty with your terminal app (e.g. iTerm2 / com.googlecode.iterm2, Terminal / com.apple.Terminal, WezTerm / com.github.wez.wezterm)
• The auto-fix script uses only macOS native tools (bash 3.2 compatible, no gawk/associative arrays)
• The LaunchAgent runs every 5 minutes and only acts when actual TCC denials are detected in the log
• Log file: ~/Library/Logs/tcc-autofix.log (empty = no issues)

Environment

• macOS 26.5.1 (Darwin 25.5.0, arm64)
• Ghostty 1.3.1
• Claude Code CLI / kimi-code CLI with multi-agent runs

That's a solid write up. It's weird though, because when I run the project (which has 200.000 files in it) through Claude Code and Docker Desktop (with this using VirtioFS), I see the file descriptors climb immediately at boot/start. If I switch Docker to using the older, and slower gRPC Fuse filesystem, my file descriptors are about halved by this operation.

It's true, that after I ran out of file descriptors, I usually see a lot of TCC "degradation", like corruption like you're pointing out.

EDIT: I've sorted the problem by moving the massive amounts of files out of the "working directory", and symlinked it in (as suggested by Claude itself). This has solved the issue for me in relation to Claude, but it still persists with Docker Desktop using VirtioFS.

I have a question, do you all use ccswitch in this case?

I'm so tired of the problem. I'm moving folders out of the icloud trap. Claude Code sessions on a folder that is not in the icloud trap do not suffer this problem.

I found moving things out of iCloud to be PAINFUL... so here's a script that will sync it, validate it, and create a symlink from the original location to the new for backward compatibility.

!! dependency:
--> install the latest rsync (6-19-2026)
--> brew install rsync

Script: sync_move_verify.sh

#!/usr/bin/env bash
set -euo pipefail

# usage: ./rsync_move_verify.sh <folder_name>
# example: ./rsync_move_verify.sh cool_project

NAME="${1:?missing folder name}"

# Change paths to your path with the source and destination for your folder
SRC="/Users/uname/Documents/repo/${NAME}"
DST="/Users/uname/repo/${NAME}"

LOG="/tmp/rsync_${NAME}_validation.txt"

echo "[1/4] sync (aggregate progress)"
# ADDED trailing slashes here so rsync still copies directory contents correctly
rsync -a --info=progress2 \
  "$SRC/" "$DST/"

echo "[2/4] validation (checksum, dry-run)"
rsync -acn --delete \
  "$SRC/" "$DST/" \
  > "$LOG"

DIFF_COUNT="$(grep -E '^[<>c\*]' "$LOG" | wc -l | tr -d ' ' || true)"

echo "[3/4] result"
if [[ "$DIFF_COUNT" == "0" ]]; then
  echo "OK: 1:1 match"
else
  echo "DIFF: $DIFF_COUNT differences (see $LOG)"
fi

echo "[4/4] cleanup + symlink (only if OK)"
if [[ "$DIFF_COUNT" == "0" ]]; then
  rm -rf "$SRC"
  ln -s "$DST" "$SRC"
  echo "CLEAN: source removed, symlink created"
else
  echo "SKIP: differences present; no cleanup performed"
fi

might be related https://www.reddit.com/r/OpenAI/comments/1ucf4px/openai_codex_has_a_bug_that_could_kill_your_ssd/ it could be the codex broken my external SSD after 2 months of heavy usage