Error: Permission denied (os error 13) – Codex seems to need $HOME write permission

Resolved 💬 9 comments Opened Aug 11, 2025 by dlejay Closed Oct 27, 2025
💡 Likely answer: A maintainer (pakrym-oai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.20.0

Which model were you using?

No idea

What platform is your computer?

Darwin 24.6.0 arm64 arm

What steps can reproduce the bug?

  • Install Codex with brew install codex
  • Run codex

What is the expected behavior?

Codex should run correctly.

What do you see instead?

Error: Permission denied (os error 13)

Additional information

In order to “Defend $HOME”, the $HOME folder is not writable.

View original on GitHub ↗

9 Comments

pakrym-oai contributor · 11 months ago

This is expected, we store session logs in ~/.codex/sessions and have some logic to update config.toml.

dlejay · 11 months ago

Well, this is not what I personally expected as a first codex experience, given that on macOS $HOME is not the recommended default location for app configuration, data, etc.

Lekyaira · 11 months ago

They are correct, this should probably be changed to $XDG_DATA_HOME/Codex or $XDG_DATA_HOME/Application Support/Codex on MacOS.

Most users won't have permissions issues with $HOME/.codex, but the above change would create more consistent behavior for MacOS users.

dlejay · 11 months ago

macOS does not follow the X Desktop Group specifications.
The default location is supposed to be ~/Library/Application Support/Codex.

Lekyaira · 11 months ago

Ah, you are correct. I was working from an Apple developer thread that seemed to indicate that $XDG_DATA_HOME pointed to ~/Library. Tested on my Macbook Sequoia 15.5, doesn't exist. I mostly work on Linux so I didn't double check.

So yes, ~/Library/Application Support/Codex would be the most normal place to store files in a MacOS environment.

Notably, you can set $CODEX_HOME in your shell to redirect this. I prefer these things to end up in ~/.config so I had to set that anyway. I haven't tested yet, but seems like it should work according to the readme?

I still second defaulting to Application Support on MacOS installs, as that is the most consistent MacOS place to store app data.

etraut-openai contributor · 8 months ago

Thanks for the bug report. Codex is working as intended here, so I'm going to close.

KiranChilledOut · 8 months ago

what worked for me on MAC OS is getting ownership of the .codex folder below is what I did
sudo chown -R $(whoami) ~/.codex
chmod -R 700 ~/.codex

rarestg · 8 months ago

I've been experiencing a related issue on macOS with npm install -g @openai/codex@latest. The installation fails with:

npm error code ENOTEMPTY
npm error errno -66
npm error ENOTEMPTY: directory not empty, rename '/Users/rares/.nvm/versions/node/v24.1.0/lib/node_modules/@openai/codex' -> '/Users/rares/.nvm/versions/node/v24.1.0/lib/node_modules/@openai/.codex-Qs27cSw0'

Workaround: I have to manually clean up before installing:

rm -rf /Users/rares/.nvm/versions/node/v24.1.0/lib/node_modules/@openai/codex
npm install -g @openai/codex@latest

However, there's an additional issue: the installed executable lacks execute permissions (644 instead of 755), which causes Permission denied errors. After installation, I have to manually fix it:

chmod +x /Users/rares/.nvm/versions/node/v24.1.0/bin/codex

This suggests the npm package installation process may not be properly preserving file permissions, or there's a cleanup/upgrade issue when updating the package. This compounds the existing permission/directory issues mentioned in this thread.

Letlaka · 1 month ago
what worked for me on MAC OS is getting ownership of the .codex folder below is what I did sudo chown -R $(whoami) ~/.codex chmod -R 700 ~/.codex

I am on arch, and this helped me, thank you.