[BUG] file-index-worker fails on all sessions rooted in ~/Documents (sandboxed git cannot read TCC-protected dirs)

Status Open
Reported on v2.1.219
Maintainer reply None cached
Activity 1 comment · opened Jul 26, 2026

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?

Every session focus or warm-up, Claude Desktop's file-index-worker runs git ls-files to
build the @-mention autocomplete index. That call fails because the helper process running
git is sandboxed without read access to macOS's protected user directories (~/Documents,
~/Desktop, ~/Downloads). The worker silently falls back to a depth-limited directory scan.

All 12 of my sessions are rooted under ~/Documents, so this fires on 100% of them —
1-5 warnings per focus event, roughly 4/min sustained, 3,200+ occurrences in my current log.

Granting the app Full Disk Access does NOT fix it. FDA was already enabled; toggling it off
and back on changed nothing. A sandbox profile is a separate enforcement layer from TCC, so
the app-level grant never reaches the helper.

The real damage is not performance — the fallback scan takes ~52ms and the node helper
processes sit at 0.0% CPU. It's that the fallback is depth-limited, so @-mention autocomplete
sees only ~2,800 of the 78,524 files in my main working folder. About 96% of my files are
silently unreachable via @-mention, with no user-visible indication that anything failed.

What Should Happen?

git ls-files should succeed for session folders under ~/Documents, and @-mention autocomplete
should index the full file tree rather than a depth-limited subset.

The file-index worker should run in a context that inherits the app's disk access, so that
granting Full Disk Access to Claude actually enables indexing of protected user directories.

Failing that, the fallback should surface to the user — currently the only signal is a warn
in main.log, so autocomplete appears to work while silently missing most files.

Error Messages/Logs

From ~/Library/Logs/Claude/main.log — fires immediately after every setFocusedSession:

2026-07-25 21:43:17 [info] [CCD] LocalSessions.setFocusedSession: sessionId=local_11364ede-190a-41af-a8c0-b0dee5e4d138
2026-07-25 21:43:17 [warn] [file-index-worker] git ls-files failed; falling back to shallow BFS (deep paths may be missing in @-mention autocomplete): fatal: Unable to read current working directory: Operation not permitted
2026-07-25 21:43:17 [warn] [file-index-worker] git ls-files failed; falling back to shallow BFS (deep paths may be missing in @-mention autocomplete): fatal: Unable to read current working directory: Operation not permitted

Occurrence count in a single log file: 3,204
Rate: 1-5 warns per setFocusedSession event, ~4/min sustained

Steps to Reproduce

  1. Put a Claude Desktop session's working folder anywhere under ~/Documents

(a folder that is NOT a git repository shows it most clearly).

  1. Focus or switch to that session.
  2. Observe the warn in ~/Library/Logs/Claude/main.log:

grep -c file-index-worker ~/Library/Logs/Claude/main.log

Isolated reproduction — same git binary, same cwd, sandbox is the only variable:

cd ~/Documents/some-non-repo-folder

/usr/bin/git ls-files
-> fatal: not a git repository (or any of the parent directories): .git

sandbox-exec -p "(version 1)(allow default)(deny file-read* (subpath \"$HOME/Documents\"))" /usr/bin/git ls-files
-> fatal: Unable to read current working directory: Operation not permitted

The second output matches the log message verbatim. Running the identical sandboxed
command from a folder OUTSIDE ~/Documents returns the ordinary "not a git repository"
error, confirming the denial is scoped to the protected directories.

RULED OUT:

  • Full Disk Access — already granted; toggling made no difference
  • git version — 2.54.0 (Homebrew), 2.50.1 (Apple Git-155), and 2.15.0 all work unsandboxed
  • Missing git repo — running git init in a failing folder did not stop the warnings
  • File permissions — all session folders readable; git works from a normal shell

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.219 (embedded)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗