I recently spent several frustrating hours troubleshooting the Codex CLI on my Mac. It was a classic developer trap: fixing one problem immediately revealed another. Broken symlinks, expired tokens, and directory permissions converged, making it feel as though the tool was simply broken.
Since "codex 401 unauthorized" is one of the most searched terms on my blog, it's clear many others are hitting these same walls. I have documented the exact sequence of failures and fixes I encountered on my Mac mini to help you avoid the rabbit hole.
Why does codex --version say No such file or directory?
When I first installed Codex via Homebrew Cask, the installation appeared successful. However, running codex --version returned No such file or directory. It turned out that while the symbolic link existed, the executable it pointed to was missing. The shell had a map to the binary, but the destination was empty.
To fix this, you must restore both the link and the executable via a clean reinstall. Run the following commands:
brew reinstall --cask codex
codex --version
Once codex --version prints the version number, you've cleared the first hurdle. Without resolving this, subsequent login or execution commands are pointless because the system cannot find the tool.
Why am I getting 401 Unauthorized during login?
Even after fixing the installation, codex login and codex exec continued to return 401 Unauthorized. Assuming my API key had expired, I generated a new one, but the error persisted.
The culprit wasn't the API key, but an expired authentication token stored in auth.json. When you reinstall or manually tweak configurations, old tokens can linger on disk. The server sees this stale token and rejects the request before considering your new key.
The solution is simple: run codex login again. This forces the CLI to fetch a fresh token and overwrite the corrupted or expired auth.json file. Remember that you must verify the version (the first step) before attempting this, otherwise the login command will not execute.
What does Not inside a trusted directory mean?
After successfully logging in, I tried running codex exec in one of my personal folders. Instead of executing, it returned: Not inside a trusted directory. While this looks like a bug, it is actually a built-in security feature.
By default, Codex CLI only executes inside folders initialized as git repositories (those with a commit history). If you attempt to run the tool in a standard folder that isn't a git repo, the CLI blocks execution to prevent accidental changes to untracked files.
To bypass this check and run the command anyway, use the following flag:
codex exec --skip-git-repo-check "..."
If you frequently work in non-git directories, make this flag a habit.
After resolving these three issues, the final verification flow is straightforward: check that codex --version prints correctly, ensure codex login finishes without errors, and verify that codex exec --skip-git-repo-check performs the task. If any of these fail, revert to the previous stage.
As a side note, if you encounter "codex CLI not found" while using a cron job, it is likely because cron has an empty PATH and cannot find the Homebrew binary path at /opt/homebrew/bin. Adding the PATH directly to your cron script solves this. Additionally, calling Codex inside a Claude Code sandbox seems to freeze the version check entirely; in that specific case, I switched to a local model.
The biggest takeaway is that these errors are cumulative. A broken link, a stale token, and a security policy each trigger different error messages. Instead of memorizing codes, simply trace which stage of the setup you are currently stuck on.
Related posts
- codex CLI login not working on macOS: what fixed it
- Claude Code: The gap between "made" and "working"
- Claude Code: Migrating 15 months of project memory
This post is the English edition of a Korean write-up: 원문 보기
Originally published at Homelab Notes — notes from one Mac mini running local LLMs and 24/7 automation.
