codex CLI login not working on macOS: what fixed it

TL;DR:

Symptom: codex --version fails with "No such file or directory", while codex login and codex exec throw 401 Unauthorized or "Not inside a trusted directory".

Cause: brew cask leaves only symlinks with missing binaries, expired tokens in auth.json, and security restrictions blocking non-git directories.

Fix: Run brew reinstall --cask codex to restore the binary, re-run codex login for a fresh token, and append --skip-git-repo-check when working outside repositories.

Why codex login alone did not clear the 401

I spent hours trying to get the codex CLI working after a clean install. The first red flag appeared when I ran codex --version. Instead of printing the installed version, it immediately crashed with "No such file or directory". This is a classic symptom of a broken package manager installation. When you install tools through brew cask, the system sometimes only writes symbolic links instead of copying the actual executable files. A symbolic link is just a reference path that points to another file, so if the target disappears, the link becomes useless. It felt like checking a skeleton and finding nothing inside.

Running brew reinstall --cask codex fixed the missing binary and restored the symlinks. codex --version started working again, which made me confident I had fixed the installation. Then came codex login. Every attempt returned 401 Unauthorized. I assumed the API key was invalid and went through the reissuing process, but the error persisted. The real issue lived inside auth.json, which stores your authentication tokens on disk. Authentication tokens are temporary credentials that prove your identity to the service. Package updates or manual edits can leave these tokens expired on disk. Running codex login again forces the CLI to generate a fresh token and overwrite the stale entry. It cleared the 401 Unauthorized response immediately.

Breaking the trusted directory check for local projects

The final hurdle appeared when I tried codex exec. Running it outside a version-controlled project triggered "Not inside a trusted directory" and refused to execute. This is not a bug; it is a built-in security measure. The CLI defaults to running only in directories that contain git commit history, assuming those are validated codebases. When I tried to apply the tool to private files or scratch projects, it blocked me without warning.

I had to dig into man codex to find the override. Adding --skip-git-repo-check disables that directory validation and lets the command run anywhere you specify. Testing codex exec --skip-git-repo-check confirmed it worked exactly as intended. After verifying that codex login succeeded and codex --version printed correctly, I stopped fighting the toolchain.

Dealing with broken symlinks, expired tokens, and hidden security checks simultaneously taught me a practical lesson. CLI failures rarely come from a single missing dependency. Package managers, local config files, and default security policies interact in ways that simple reinstallation cannot fix. You have to trace each error back to its actual source before applying the next command. Understanding how your package manager and tool defaults interact saves more time than memorizing error codes.