How to fix error: unable to access path: Operation not permitted (requires Full Disk Access) in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 342 views

This macOS error occurs when Git attempts to access files or directories in protected locations but lacks Full Disk Access permission. Starting with macOS Mojave (10.14), Apple introduced stricter privacy protections that require explicit user authorization for applications to access certain directories.

Quick fix

Fixes EPERM

# Run the Git command with verbose output
GIT_TRACE=1 git status 2>&1 | grep -i "permission\|not permitted"

# Or check the specific path mentioned in the error
ls -la /path/to/problematic/directory
  1. Identify the protected path causing the error
  2. Grant Full Disk Access to Terminal
  3. Grant Full Disk Access to your IDE or code editor
  4. Grant Full Disk Access to Git itself
git — error
# Run the Git command with verbose output
GIT_TRACE=1 git status 2>&1 | grep -i "permission\|not permitted"
# Or check the specific path mentioned in the error
ls -la /path/to/problematic/directory
error: unable to access path: Operation not permitted (requires Full Disk Access)

What this error means

This error indicates that Git (or the terminal application running Git) is trying to access a file or directory that macOS considers protected under its Privacy & Security framework. The "Operation not permitted" error with the Full Disk Access requirement is part of Apple's Transparency, Consent, and Control (TCC) security system. Starting with macOS Mojave (10.14) and strengthened in subsequent versions, macOS restricts access to certain directories and file types even for applications running with administrator privileges. These protected locations include: - Desktop, Documents, and Downloads folders (in some configurations) - iCloud Drive - Third-party cloud storage folders (Dropbox, Google Drive, OneDrive) - Mail, Messages, and Safari data - Time Machine backups - System files and certain application data When Git tries to read, write, or traverse directories in these protected areas without the necessary permissions, macOS blocks the operation and returns an "Operation not permitted" error. This commonly happens when cloning repositories into protected folders, running Git commands in directories synced by cloud services, or accessing files in the user's Desktop or Documents folders from a terminal or IDE that lacks Full Disk Access.

Typical symptoms

  • Git clone, pull, push, or status fails with 'Operation not permitted' on macOS
  • Git commands work in some directories but fail in Documents, Desktop, or cloud-synced folders
  • Error occurs after upgrading macOS to Mojave or later
  • IDE or code editor Git integration fails while Terminal works (or vice versa)
  • CI/CD tools or automation scripts fail with permission errors on macOS
  • Git commands fail when accessing files in iCloud Drive
  • Error appears when running Git in Dropbox, Google Drive, or OneDrive folders
  • 'fatal: could not open directory' errors in protected locations
  • Git hooks fail with permission denied in protected directories
  • Submodule operations fail in protected parent directories

Common causes

  1. Terminal application lacks Full Disk Access permission in macOS Privacy settings
  2. IDE or code editor running Git lacks Full Disk Access permission
  3. Repository or working directory is in a macOS-protected location
  4. Files are stored in iCloud Drive or another cloud-synced folder
  5. Git hooks or scripts trying to access protected directories
  6. Running Git from an application that has not been granted necessary permissions
  7. macOS upgraded to Mojave or later without re-authorizing applications
  8. Sandboxed application restrictions preventing file access
  9. System Integrity Protection (SIP) blocking access to certain paths
  10. Extended attributes or ACLs on files preventing access

How to fix "error: unable to access path: Operation not permitted (requires Full Disk Access)"

1Identify the protected path causing the error

First, determine exactly which path is triggering the permission error:

Check the full error message:

bash
# Run the Git command with verbose output
GIT_TRACE=1 git status 2>&1 | grep -i "permission\|not permitted"

# Or check the specific path mentioned in the error
ls -la /path/to/problematic/directory

Common protected locations on macOS:
- ~/Desktop - Desktop folder
- ~/Documents - Documents folder
- ~/Downloads - Downloads folder
- ~/Library/Mobile Documents - iCloud Drive
- ~/Dropbox - Dropbox folder
- ~/Google Drive - Google Drive folder
- ~/OneDrive - OneDrive folder

Check if the error is TCC-related:

bash
# Look for TCC denials in system log
log show --predicate 'subsystem == "com.apple.TCC"' --last 5m

Understanding which path is protected helps determine the right solution.

2Grant Full Disk Access to Terminal

The most common fix is granting Full Disk Access to your terminal application:

For Terminal.app:
1. Open System Preferences (or System Settings on macOS Ventura+)
2. Go to Privacy & Security > Privacy tab
3. Select Full Disk Access from the left sidebar
4. Click the lock icon and enter your password to make changes
5. Click the + button
6. Navigate to /Applications/Utilities/Terminal.app
7. Add Terminal to the list and ensure the checkbox is enabled
8. Quit and reopen Terminal for changes to take effect

For iTerm2:
1. Follow the same steps as above
2. Add /Applications/iTerm.app instead

For other terminal emulators:
Add the specific application (Hyper, Alacritty, Warp, etc.) using the same process.

Verify the permission was granted:

bash
# After restarting Terminal, try accessing a protected path
ls ~/Desktop
cd ~/Documents && git status

Important: You must quit and reopen the terminal application after granting permissions.

3Grant Full Disk Access to your IDE or code editor

If you're using Git through an IDE, the IDE itself needs Full Disk Access:

For Visual Studio Code:
1. Open System Preferences > Privacy & Security > Full Disk Access
2. Click the lock and authenticate
3. Click + and add /Applications/Visual Studio Code.app
4. Restart VS Code completely

For JetBrains IDEs (IntelliJ, WebStorm, PyCharm, etc.):
1. Add the specific IDE app from /Applications/
2. For example: /Applications/IntelliJ IDEA.app

For Xcode:
1. Add /Applications/Xcode.app
2. Also consider adding /Library/Developer/CommandLineTools if using command-line tools

For Sublime Text, Atom, or other editors:
Add the respective application from your Applications folder.

Common IDE locations:

bash
/Applications/Visual Studio Code.app
/Applications/Sublime Text.app
/Applications/IntelliJ IDEA.app
/Applications/PyCharm.app
/Applications/WebStorm.app
/Applications/Xcode.app

After adding the IDE, restart it completely (quit and reopen).

4Grant Full Disk Access to Git itself

In some cases, you may need to grant access to the Git binary directly:

Find your Git installation:

bash
# Find which Git you're using
which git

# Common locations:
# /usr/bin/git - Apple's built-in Git
# /usr/local/bin/git - Homebrew Git (Intel Macs)
# /opt/homebrew/bin/git - Homebrew Git (Apple Silicon)
# /Applications/Xcode.app/Contents/Developer/usr/bin/git - Xcode Git

Add Git to Full Disk Access:
1. Open System Preferences > Privacy & Security > Full Disk Access
2. Click + and press Cmd+Shift+G to open "Go to folder"
3. Enter the path to your Git binary (e.g., /usr/local/bin/git)
4. Select the git file and click Open

For Homebrew Git:

bash
# Find the actual binary location
readlink -f $(which git)
# This might show something like:
# /opt/homebrew/Cellar/git/2.43.0/bin/git

Note: Adding just the terminal application usually suffices. Only add Git directly if terminal access doesn't resolve the issue.

5Move repository to a non-protected location

If granting Full Disk Access isn't desirable or possible, move your repository to an unprotected location:

Create a development directory outside protected areas:

bash
# Create a dev folder in your home directory (not protected by default)
mkdir -p ~/dev

# Move your repository
mv ~/Documents/my-project ~/dev/my-project

# Or clone to the new location
git clone https://github.com/user/repo.git ~/dev/repo

Safe locations for Git repositories:
- ~/dev or ~/code - Custom development folders
- ~/projects - Project directory
- /usr/local/src - Local source directory (may need sudo)
- Any custom folder you create outside Desktop/Documents

Update your IDE workspace:
After moving the repository, update any IDE projects or workspace files to point to the new location.

Create a symlink (optional):

bash
# If you need the project accessible from Documents
ln -s ~/dev/my-project ~/Documents/my-project

This approach avoids security permission issues entirely.

6Handle iCloud Drive repositories

If your repository is in iCloud Drive, you have several options:

Option 1: Move out of iCloud Drive

bash
# Find your iCloud Drive path
cd ~/Library/Mobile\ Documents/com~apple~CloudDocs

# Move repository to a local folder
mv my-repo ~/dev/my-repo

Option 2: Disable iCloud Desktop & Documents sync for development folders
1. Open System Preferences > Apple ID > iCloud
2. Click Options next to iCloud Drive
3. Uncheck Desktop & Documents Folders

Option 3: Grant Full Disk Access (see Step 2)
This allows Git to access iCloud Drive, but may cause issues with cloud sync.

Best practice for iCloud users:
Keep Git repositories outside of iCloud-synced folders. Cloud sync and Git don't mix well due to:
- .git folder can become corrupted during sync
- File locking conflicts
- Large repository sizes consuming iCloud storage
- Sync delays causing inconsistent state

bash
# Recommended: Keep code separate
~/dev/           # Git repositories (local only)
~/Documents/     # iCloud-synced documents
7Handle Dropbox/Google Drive/OneDrive repositories

Similar to iCloud, repositories in cloud-synced folders require special handling:

Move repository out of cloud folder:

bash
# Example for Dropbox
mv ~/Dropbox/projects/my-repo ~/dev/my-repo

# Update remote if needed
cd ~/dev/my-repo
git remote -v

Grant Full Disk Access to terminal and cloud client:
If you must keep repositories in cloud folders, grant Full Disk Access to:
1. Your terminal application
2. The cloud sync application (Dropbox, Google Drive, OneDrive)

Exclude .git folders from sync:
Some cloud clients allow excluding folders:

Dropbox:

bash
# Use Selective Sync or add .git to ignore
# Or use the xattr command
xattr -w com.dropbox.ignored 1 .git

Google Drive:
Right-click folder in Finder > "Do not sync"

OneDrive:
Use the "Free up space" option or exclude via settings.

Best practice: Don't store Git repositories in cloud-synced folders. Use Git remotes (GitHub, GitLab) for backup and collaboration instead.

8Fix permission errors with Git hooks

If Git hooks are failing due to permission errors:

Check hook permissions:

bash
# List hooks and their permissions
ls -la .git/hooks/

# Make hooks executable
chmod +x .git/hooks/*

Ensure hooks can access required paths:
If a hook script accesses protected directories, either:
1. Grant Full Disk Access to the terminal running Git
2. Modify the hook to avoid protected paths
3. Use environment variables for paths

Example: Pre-commit hook accessing Documents:

bash
#!/bin/bash
# Before (problematic):
# DOCS_PATH="$HOME/Documents/templates"

# After (use unprotected location):
DOCS_PATH="$HOME/dev/templates"

For Husky or other Git hook managers:
Ensure the Node.js or script interpreter has Full Disk Access if needed:

bash
# Find node location
which node
# Add to Full Disk Access if necessary

Debug hook execution:

bash
# Run hook manually to see errors
.git/hooks/pre-commit
9Reset TCC database (advanced troubleshooting)

If permissions seem correct but Git still fails, the TCC database may be corrupted:

Warning: This resets all privacy permissions and requires re-authorizing all applications.

Reset via Terminal (requires SIP disabled or Recovery Mode):

bash
# This usually doesn't work with SIP enabled
tccutil reset All

Reset specific service:

bash
# Reset just Full Disk Access
tccutil reset SystemPolicyAllFiles

More reliable: Reset via System Preferences
1. Go to System Preferences > Privacy & Security > Full Disk Access
2. Remove the application (Terminal, IDE, etc.)
3. Re-add the application
4. Restart the application

Check TCC database status:

bash
# View TCC log entries
log show --predicate 'subsystem == "com.apple.TCC"' --last 10m --info

# Find TCC database (read-only without SIP disabled)
ls -la ~/Library/Application\ Support/com.apple.TCC/TCC.db

If nothing works:
Consider creating a new macOS user account and testing Git there to rule out user-specific corruption.

10Verify fix and test Git operations

After applying fixes, verify that Git works correctly:

Test basic operations:

bash
# Navigate to the previously problematic directory
cd /path/to/repository

# Test status
git status

# Test fetching
git fetch origin

# Test file operations
git diff
git log --oneline -5

Test in previously blocked locations:

bash
# Test in Documents (if that was the issue)
cd ~/Documents
mkdir test-repo && cd test-repo
git init
echo "test" > README.md
git add .
git commit -m "Test commit"

# Clean up
cd ..
rm -rf test-repo

Test IDE integration:
1. Open your IDE
2. Open a project in the previously problematic location
3. Make a change and verify Git detects it
4. Try committing through the IDE

If issues persist:

bash
# Check for extended attributes
xattr -l /path/to/file

# Remove problematic attributes if safe
xattr -c /path/to/file

Advanced notes

### Understanding macOS TCC (Transparency, Consent, and Control)

The TCC framework was introduced in macOS Mojave to give users more control over their data. It requires explicit user consent before applications can access:

1. Protected User Data: Desktop, Documents, Downloads (when iCloud-synced), Photos, Calendars, Reminders, etc.
2. Hardware: Camera, Microphone, Screen Recording
3. System Services: Accessibility, Full Disk Access, Automation

Full Disk Access is the broadest permission, granting access to almost all user data. It's required for:
- Backup applications
- Antivirus/security software
- Development tools that need to access arbitrary files
- Terminal applications running commands in protected directories

### How TCC Affects Git

When Git runs, it inherits the permissions of its parent process:

bash
Terminal.app (Full Disk Access: Yes)
  └── bash
       └── git status  ← Can access protected directories

VS Code (Full Disk Access: No)
  └── node
       └── git status  ← Cannot access protected directories

This is why the same Git command might work in Terminal but fail in VS Code.

### System Integrity Protection (SIP) and TCC

SIP protects system files and the TCC database. With SIP enabled:
- You cannot directly modify the TCC database
- tccutil commands are limited
- Legitimate permission grants through System Preferences work normally

Never disable SIP just to fix permission issues. Use the proper System Preferences method instead.

### Checking Permission Status Programmatically

For automation or debugging:

bash
# Check if an app has Full Disk Access (indirect method)
# This attempts to read a protected file
if sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "" 2>/dev/null; then
    echo "Has Full Disk Access"
else
    echo "Does not have Full Disk Access"
fi

### Managed Devices and MDM

On enterprise Macs managed via MDM:
- IT administrators can pre-authorize Full Disk Access
- Privacy Preferences Policy Control (PPPC) profiles can grant permissions
- Users may not be able to modify certain security settings

If you're on a managed device and can't grant permissions, contact your IT administrator.

### Apple Silicon Considerations

On M1/M2/M3 Macs:
- Rosetta 2 may affect how permissions are inherited
- Native ARM binaries may need separate authorization from x86 versions
- Homebrew location is /opt/homebrew vs /usr/local

bash
# Check architecture
uname -m  # arm64 for Apple Silicon

# Check if running under Rosetta
sysctl -n sysctl.proc_translated  # 1 if Rosetta, 0 if native

### Debugging Permission Denials

Use Console.app or the log command to see TCC denials in real-time:

bash
# Stream TCC-related log entries
log stream --predicate 'subsystem == "com.apple.TCC"' --level info

# In another terminal, run the failing Git command
git status

Look for entries like:

bash
default: tccd: denied process 1234 (git) access to ...

### Alternatives to Full Disk Access

If you don't want to grant Full Disk Access:

1. Move repositories to unprotected locations
2. Use symbolic links from protected to unprotected directories
3. Use SSH remotes and keep code on a server
4. Use Docker to isolate Git operations (Docker has its own Full Disk Access)

### Recovery Options

If you've made changes that break Git entirely:

1. Boot to Recovery Mode: Hold Cmd+R (Intel) or long-press power button (Apple Silicon)
2. Disable SIP temporarily: csrutil disable (not recommended)
3. Reset NVRAM: Shut down, then hold Opt+Cmd+P+R during startup
4. Create new user: Test if Git works in a fresh user account
5. Reinstall Command Line Tools: xcode-select --install

Frequently asked questions

What does "EPERM" mean?
This error indicates that Git (or the terminal application running Git) is trying to access a file or directory that macOS considers protected under its Privacy & Security framework. The "Operation not permitted" error with the Full Disk Access requirement is part of Apple's Transparency, Consent, and Control (TCC) security system. 14) and strengthened in subsequent versions, macOS restricts access to certain directories and file types even for applications running with administrator privileges.
How do I fix "EPERM"?
This macOS error occurs when Git attempts to access files or directories in protected locations but lacks Full Disk Access permission. Starting with macOS Mojave (10.14), Apple introduced stricter privacy protections that require explicit user authorization for applications to access certain directories.
What causes "EPERM"?
Terminal application lacks Full Disk Access permission in macOS Privacy settings IDE or code editor running Git lacks Full Disk Access permission Repository or working directory is in a macOS-protected location
Is the "EPERM" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading