›_ Claude Code Issues
Claude Code Issues / #93747

[BUG] Desktop app can't access Documents folder despite TCC grant — fragmented/duplicate app identities in Files & Folders

Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Sep 12, 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?

Summary

The Claude desktop app (macOS) fails to read files under ~/Documents, raising an
EPERM ("Operation not permitted") error, even after granting Files & Folders access
in System Settings, restarting the app, restarting the Mac, and resetting the TCC
permission database entry for the app.

Environment

  • macOS version: [run sw_vers -productVersion and paste result]
  • Claude desktop app version: [Claude menu → About Claude, or Settings → About]
  • Mac: not MDM-managed (confirmed via System Settings → General → Device Management —

only an unrelated iOS provisioning profile is present)

Steps to reproduce

  1. Open a new Claude Code session rooted at a folder inside ~/Documents

(e.g. ~/Documents/GMOPaymentsJava).

  1. Ask Claude to read any file in that folder.
  2. Observe: "Couldn't access Documents — macOS blocked Claude Code from reading this

folder" error dialog.

  1. Go to System Settings → Privacy & Security → Files and Folders → grant

"Documents Folder" access to Claude. Quit and relaunch the app. Retry step 2.
Same error persists.

  1. Ran tccutil reset SystemPolicyDocumentsFolder com.anthropic.claudefordesktop

in Terminal, relaunched the app, retried. Same error, and no fresh permission
prompt appeared at all.

  1. Tested with a brand-new unrelated file directly in ~/Documents

(not just the original folder) — same failure, ruling out a file/folder-specific
issue.

  1. Checked System Settings → Privacy & Security → Files and Folders directly:

found MULTIPLE duplicate entries for the app — several generic "claude" entries
and one "claude.app" entry. The "claude.app" entry (currently highlighted/active
icon) has NO Documents Folder row at all — only Full Disk Access and iCloud
Drive. A separate, different "claude" entry (generic icon, likely an internal
helper binary bundled with the app) DOES have Documents Folder toggled ON.

Expected behavior

Granting Documents Folder access to the Claude app in System Settings should let
the running app read files in ~/Documents.

Actual behavior

Permission appears fragmented across multiple distinct TCC/app identities on disk
(possibly due to different code-signing identities across app updates, or an
internal helper process using a different bundle identifier than the main app).
The identity that actually needs Documents access when running a session doesn't
match the identity(ies) System Settings lets you grant it to, so no combination of
toggling in Settings fixes it.

Screenshots

[attach the screenshots from this conversation showing: the "Couldn't access
Documents" error dialog, the Files & Folders list showing duplicate claude/claude.app
entries, and the one working "claude" entry with Documents Folder already ON]

Workaround

Running Claude Code via the terminal CLI (claude command, launched from within
~/Documents/GMOPaymentsJava) works fine — this issue is specific to the desktop app.

What Should Happen?

Summary

The Claude desktop app (macOS) fails to read files under ~/Documents, raising an
EPERM ("Operation not permitted") error, even after granting Files & Folders access
in System Settings, restarting the app, restarting the Mac, and resetting the TCC
permission database entry for the app.

Environment

  • macOS version: [run sw_vers -productVersion and paste result]
  • Claude desktop app version: [Claude menu → About Claude, or Settings → About]
  • Mac: not MDM-managed (confirmed via System Settings → General → Device Management —

only an unrelated iOS provisioning profile is present)

Steps to reproduce

  1. Open a new Claude Code session rooted at a folder inside ~/Documents

(e.g. ~/Documents/GMOPaymentsJava).

  1. Ask Claude to read any file in that folder.
  2. Observe: "Couldn't access Documents — macOS blocked Claude Code from reading this

folder" error dialog.

  1. Go to System Settings → Privacy & Security → Files and Folders → grant

"Documents Folder" access to Claude. Quit and relaunch the app. Retry step 2.
Same error persists.

  1. Ran tccutil reset SystemPolicyDocumentsFolder com.anthropic.claudefordesktop

in Terminal, relaunched the app, retried. Same error, and no fresh permission
prompt appeared at all.

  1. Tested with a brand-new unrelated file directly in ~/Documents

(not just the original folder) — same failure, ruling out a file/folder-specific
issue.

  1. Checked System Settings → Privacy & Security → Files and Folders directly:

found MULTIPLE duplicate entries for the app — several generic "claude" entries
and one "claude.app" entry. The "claude.app" entry (currently highlighted/active
icon) has NO Documents Folder row at all — only Full Disk Access and iCloud
Drive. A separate, different "claude" entry (generic icon, likely an internal
helper binary bundled with the app) DOES have Documents Folder toggled ON.

Expected behavior

Granting Documents Folder access to the Claude app in System Settings should let
the running app read files in ~/Documents.

Actual behavior

Permission appears fragmented across multiple distinct TCC/app identities on disk
(possibly due to different code-signing identities across app updates, or an
internal helper process using a different bundle identifier than the main app).
The identity that actually needs Documents access when running a session doesn't
match the identity(ies) System Settings lets you grant it to, so no combination of
toggling in Settings fixes it.

Screenshots

[attach the screenshots from this conversation showing: the "Couldn't access
Documents" error dialog, the Files & Folders list showing duplicate claude/claude.app
entries, and the one working "claude" entry with Documents Folder already ON]

Workaround

Running Claude Code via the terminal CLI (claude command, launched from within
~/Documents/GMOPaymentsJava) works fine — this issue is specific to the desktop app.

Error Messages/Logs

Steps to Reproduce

Summary

The Claude desktop app (macOS) fails to read files under ~/Documents, raising an
EPERM ("Operation not permitted") error, even after granting Files & Folders access
in System Settings, restarting the app, restarting the Mac, and resetting the TCC
permission database entry for the app.

Environment

  • macOS version: [run sw_vers -productVersion and paste result]
  • Claude desktop app version: [Claude menu → About Claude, or Settings → About]
  • Mac: not MDM-managed (confirmed via System Settings → General → Device Management —

only an unrelated iOS provisioning profile is present)

Steps to reproduce

  1. Open a new Claude Code session rooted at a folder inside ~/Documents

(e.g. ~/Documents/GMOPaymentsJava).

  1. Ask Claude to read any file in that folder.
  2. Observe: "Couldn't access Documents — macOS blocked Claude Code from reading this

folder" error dialog.

  1. Go to System Settings → Privacy & Security → Files and Folders → grant

"Documents Folder" access to Claude. Quit and relaunch the app. Retry step 2.
Same error persists.

  1. Ran tccutil reset SystemPolicyDocumentsFolder com.anthropic.claudefordesktop

in Terminal, relaunched the app, retried. Same error, and no fresh permission
prompt appeared at all.

  1. Tested with a brand-new unrelated file directly in ~/Documents

(not just the original folder) — same failure, ruling out a file/folder-specific
issue.

  1. Checked System Settings → Privacy & Security → Files and Folders directly:

found MULTIPLE duplicate entries for the app — several generic "claude" entries
and one "claude.app" entry. The "claude.app" entry (currently highlighted/active
icon) has NO Documents Folder row at all — only Full Disk Access and iCloud
Drive. A separate, different "claude" entry (generic icon, likely an internal
helper binary bundled with the app) DOES have Documents Folder toggled ON.

Expected behavior

Granting Documents Folder access to the Claude app in System Settings should let
the running app read files in ~/Documents.

Actual behavior

Permission appears fragmented across multiple distinct TCC/app identities on disk
(possibly due to different code-signing identities across app updates, or an
internal helper process using a different bundle identifier than the main app).
The identity that actually needs Documents access when running a session doesn't
match the identity(ies) System Settings lets you grant it to, so no combination of
toggling in Settings fixes it.

Screenshots

[attach the screenshots from this conversation showing: the "Couldn't access
Documents" error dialog, the Files & Folders list showing duplicate claude/claude.app
entries, and the one working "claude" entry with Documents Folder already ON]

Workaround

Running Claude Code via the terminal CLI (claude command, launched from within
~/Documents/GMOPaymentsJava) works fine — this issue is specific to the desktop app.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.52386.3

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Permission denied errors

Browse all Claude Code issue topics →