Provider update always fails

T3 Code's in-app Codex update loops or fails every time. Usually npm global permissions or a stale lock — here's how to update manually and stop it recurring.

Last reviewed 2026-07-27 · verified against the pingdotgg/t3code repo

T3 Code offers to update your provider, you accept, and it fails — every time, in a loop. This has been reported as Codex updates always failing.

Fix it manually first#

Skip the in-app path and update the CLI yourself:

npm i -g @openai/codex@latest
codex --version

Then fully restart T3 Code — quit the app or kill the npx t3 process, don't just refresh.

If the manual update works, the CLI was never the problem: T3 Code's update mechanism couldn't do something you can do from a shell. Almost always permissions.

Why the in-app update fails#

npm global permissions#

The most common cause. T3 Code shells out to npm, and npm can't write to the global directory:

npm config get prefix
ls -la $(npm config get prefix)/lib/node_modules

If that directory is root-owned and you aren't running as root, every global install fails.

The right fix — move the global prefix somewhere you own, rather than reaching for sudo:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.profile
source ~/.profile
npm i -g @openai/codex@latest

On Windows, if npm's global directory sits under Program Files, either run the update from an elevated PowerShell once, or reinstall Node so the prefix lands under %APPDATA%\npm.

A stale lock from a crashed update#

An interrupted update can leave a lock behind:

npm cache clean --force
rm -rf ~/.npm/_locks        # macOS / Linux

npm cache clean --force
Remove-Item "$env:LOCALAPPDATA\npm-cache\_locks" -Recurse -Force -ErrorAction SilentlyContinue

Then retry.

The wrong binary is being updated#

If you have two Codex installs, the update may be succeeding — on the one that isn't being used. T3 Code then still sees the old version, so it offers the update again. That's the loop.

which -a codex     # macOS / Linux
where.exe codex    # Windows

Remove the duplicate. PATH diagnosis →

A running process holds the file#

On Windows especially, you can't replace a binary that's executing:

tasklist | findstr codex
taskkill /PID <pid> /F

Quit T3 Code entirely before updating. It spawns provider subprocesses, so "entirely" includes the tray.

Network restrictions#

On a corporate network, npm may need a proxy or registry configuration that T3 Code's subprocess doesn't inherit:

npm config get registry
npm config get proxy

If a proxy is required, ensure it's in npm's own config rather than only in your shell environment.

Stop it recurring#

• Update providers manually. It's one command, and you get real error output when it fails.
• Own your npm prefix. Set it under your home directory once and most global-install problems disappear permanently.
• Quit T3 Code before updating, so no subprocess is holding files.
• Update both sides together — T3 Code and the provider CLI. Version guidance →

FAQ#

Why does the Codex update keep failing in T3 Code?#

Most often npm can't write to the global install directory. Update manually with npm i -g @openai/codex@latest to see the real error, then fix the permissions by moving your npm prefix somewhere you own.

How do I update Codex for T3 Code manually?#

Run npm i -g @openai/codex@latest, confirm with codex --version, then fully restart T3 Code so it picks up the new binary.

Should I use sudo to fix npm permission errors?#

No. It leaves root-owned files in your npm tree and breaks later installs. Set your npm prefix to a directory you own, such as ~/.npm-global, and add its bin to your PATH.

Why does T3 Code keep offering the same update?#

Likely you have two installs of the CLI and the update is landing on the one T3 Code isn't using. Check with which -a codex and remove the duplicate.