Geminibeginner

Fix Gemini CLI Permission Denied Errors: File Access & Directory Permissions

Resolve Gemini CLI 'permission denied' errors when reading or writing files. Fix EACCES errors, directory access issues, and file ownership problems on macOS, Windows, and Linux.

8 min readUpdated January 2026

Want us to handle this for you?

Get expert help →

When Gemini CLI encounters "permission denied" errors, it means the operating system is blocking file access. This is different from sandbox restrictions - these are OS-level permission issues that affect any program running as your user.

Understanding Permission Denied Errors

Gemini CLI runs with your user account's permissions. When you see errors like these, the underlying OS is blocking access:

Error: EACCES: permission denied, open '/path/to/file'
Error: EPERM: operation not permitted
Error: Permission denied: cannot read file

Common causes include:

  • Files owned by root or another user
  • Restrictive file permissions (e.g., 600 = owner-only)
  • Missing execute permission on parent directories
  • Files locked by other processes
  • SELinux/AppArmor policies (Linux)
  • System Integrity Protection (macOS)

Diagnosing Permission Issues

Check File Ownership and Permissions

# View file details
ls -la /path/to/file

# Example output:
# -rw-r--r--  1 root  wheel  1234 Jan 15 10:00 config.yaml
#  ^^^^^^^^^    ^^^^  ^^^^^
#  permissions  owner group

Permission breakdown:

  • First character: file type (- = file, d = directory)
  • Characters 2-4: owner permissions (rwx)
  • Characters 5-7: group permissions (rwx)
  • Characters 8-10: others permissions (rwx)
SymbolMeaningNumeric
rRead4
wWrite2
xExecute (or traverse for directories)1
-No permission0

Check Parent Directory Permissions

You need execute (x) permission on all parent directories to access a file:

# Check entire path
namei -l /path/to/problematic/file

# Or manually check each level
ls -la /path
ls -la /path/to
ls -la /path/to/problematic

Fixing Common Permission Errors

Error: File Owned by Root

Symptom: Cannot edit system configuration files or files created with sudo.

# Check ownership
ls -la /etc/myapp/config.yaml
# -rw-r--r--  1 root  root  1234 Jan 15 10:00 config.yaml

Solutions:

  1. Change ownership (if appropriate):

    sudo chown $(whoami) /path/to/file
    
  2. Copy, edit, move back:

    cp /etc/myapp/config.yaml ~/config.yaml.tmp
    # Edit with Gemini in home directory
    sudo mv ~/config.yaml.tmp /etc/myapp/config.yaml
    
  3. Use sudo for the specific operation (outside Gemini):

    sudo nano /etc/myapp/config.yaml
    

Error: Directory Not Writable

Symptom: Can read files but cannot create or modify them.

# Check directory permissions
ls -la /path/to/directory
# drwxr-xr-x  5 otheruser  staff  160 Jan 15 10:00 directory

Solutions:

  1. Add write permission for your user:

    sudo chmod o+w /path/to/directory
    # Or change ownership
    sudo chown $(whoami) /path/to/directory
    
  2. Work in a different directory and copy files after:

    # Create files in home directory, then move with sudo
    

Error: node_modules Permission Issues

Symptom: Cannot modify node_modules after running npm with sudo.

# Check ownership
ls -la node_modules
# drwxr-xr-x  500 root  root  16000 Jan 15 10:00 node_modules

Solution:

# Fix ownership recursively
sudo chown -R $(whoami) node_modules

# Prevent future issues - never use sudo with npm
# If npm requires sudo, fix npm permissions instead:
mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc
source ~/.zshrc

Error: .git Directory Access Denied

Symptom: Git operations or Gemini file access fails in repositories.

# Fix .git ownership
sudo chown -R $(whoami) .git

# Also fix file permissions if needed
chmod -R u+rw .git

Error: Cannot Access Hidden Files

Symptom: Files starting with . (like .env, .gitignore) are inaccessible.

# Check hidden file permissions
ls -la .env
# -rw-------  1 otheruser  staff  256 Jan 15 10:00 .env

Solution:

# Add read permission
chmod u+r .env
# Or change ownership
sudo chown $(whoami) .env

Platform-Specific Fixes

macOS

System Integrity Protection (SIP) protects system directories. You cannot write to:

  • /System
  • /bin
  • /sbin
  • /usr (except /usr/local)

These restrictions apply even with sudo. This is by design for security.

Full Disk Access may be required for some directories:

  1. Open System Settings > Privacy & Security > Full Disk Access
  2. Add your terminal application (Terminal.app, iTerm, etc.)
  3. Restart the terminal

Windows

Administrator vs. User context:

# Check if running as admin
whoami /groups | findstr /i "S-1-5-32-544"

# Take ownership of a file
takeown /f "C:\path\to\file"

# Grant full control
icacls "C:\path\to\file" /grant %username%:F

Windows Defender may lock files during scanning:

  • Wait a few seconds and retry
  • Add your project folder to Defender exclusions if needed

Linux

SELinux (RHEL, CentOS, Fedora):

# Check if SELinux is blocking
ausearch -m avc -ts recent

# View SELinux context
ls -Z /path/to/file

# Temporarily set permissive mode (for testing only)
sudo setenforce 0

AppArmor (Ubuntu, Debian):

# Check AppArmor status
sudo aa-status

# View denied operations
sudo dmesg | grep apparmor

Preventing Permission Issues

Best Practices

  1. Never use sudo with package managers (npm, pip, gem):

    # Bad
    sudo npm install -g package
    
    # Good - fix npm prefix instead
    npm config set prefix ~/.npm-global
    
  2. Clone repositories to your home directory:

    # Good
    git clone repo ~/projects/myproject
    
    # Problematic
    sudo git clone repo /opt/myproject
    
  3. Use appropriate umask:

    # Check current umask
    umask
    
    # Set reasonable default (files: 644, directories: 755)
    umask 022
    
  4. Use groups for shared access:

    # Create a group for project access
    sudo groupadd myproject
    sudo usermod -aG myproject $(whoami)
    sudo chown -R :myproject /path/to/project
    sudo chmod -R g+rw /path/to/project
    

Quick Permission Reference

NumericSymbolicUse Case
755rwxr-xr-xDirectories, executable scripts
644rw-r--r--Regular files
600rw-------Private files (credentials)
700rwx------Private directories

Troubleshooting Checklist

If you're still getting permission denied errors:

  • Check file ownership: ls -la /path/to/file
  • Check directory permissions: ls -la /path/to/
  • Check parent directories: namei -l /path/to/file
  • Verify your username: whoami
  • Check for file locks: lsof /path/to/file
  • Review SELinux/AppArmor logs (Linux)
  • Check Full Disk Access settings (macOS)
  • Temporarily disable antivirus to test (Windows)

Frequently Asked Questions

Find answers to common questions

Gemini CLI runs with your user permissions. If a file is owned by root or another user, or has restrictive permissions (like 600), Gemini cannot modify it. Check ownership with 'ls -la filename' and fix with 'chown' or 'chmod' commands.

Need Professional IT & Security Help?

Our team of experts is ready to help protect and optimize your technology infrastructure.