Codex CLI 401 Unauthorized and Installation Fixes

Codex CLI 401 Unauthorized and Installation Fixes

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.

Codex CLI 401 Unauthorized and Installation Fixes

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

This post is the English edition of a Korean write-up: 원문 보기

Comments

Post a Comment

Popular posts from this blog

npm command not found on Windows: fix the PATH

Image
I recently hit a wall while configuring my development environment on Windows. It's one of those subtle issues that can waste an afternoon if you don't know what to look for. Here's exactly how I diagnosed and fixed a 'command not found' error after a successful global install. The Problem I decided to add a markdown processing tool to my toolkit by running: npm install -g markdown-it-cli The terminal output confirmed the installation succeeded, displaying a message about added packages. Satisfied, I tried to use it by typing markdown-it-cli in the command line. Windows immediately responded with: 'markdown-it-cli is not recognized as an internal or external command, operable program or batch file.' This error means Windows looked through every folder in its search list and couldn't find an executable with that name. Attempts and Failures My initial reaction was to suspect the package itself might be broken. I tried running it using npx , wh...
Read more

Claude CLI 401 Unauthorized Refresh Token Issue

Symptom: claude commands fail with 401 Unauthorized and the message "refresh token was already used. Please log out and sign in again." Cause: The refresh token expired after being consumed by another session or a background process. Refresh tokens are single-use credentials. Fix: Run claude auth login to refresh authentication without running a logout command first. Why claude login alone did not clear the 401 I was running a pipeline command when every subsequent CLI call failed. The terminal returned this exact output: Error: 401 Unauthorized Message: "Authentication failed: refresh token was already used. Please log out and sign in again." Code: "AUTH_ERROR" The error text explicitly instructs me to log out. I spent roughly ten minutes searching the terminal for a logout function. The prompt only showed AUTH_ERROR . I assumed clearing old sessions was required first. That assumption blocked progress. The instructions in the error message ...
Read more

Tailscale without sudo: what userspace mode actually costs you

At first, I installed Tailscale on macOS knowing I did not have admin rights to write to system directories. The CLI package installed cleanly enough, landing entirely within my user space without triggering any permission errors or requiring elevated prompts. The installation process felt seamless, but the friction appeared immediately during usage. Every single command I typed required appending --socket=$HOME/.tailscale/tailscaled.sock to talk to the daemon. I found myself adding this flag to status checks, key generation, and connection queries across multiple sessions. The repetition was exhausting for a tool I expected to run in the background, turning routine operations into a chore. I eventually wrote a shell function to wrap this flag, allowing me to call tailscale directly without typing the socket path every time. This workaround saved my sanity but highlighted that userspace mode demands extra configuration just to use the CLI, and any automation scripts I maintained had...
Read more