Codex CLI permanently fails with 401 on Linux VMs despite valid API key - auth.json not updated by codex login

What version of Codex CLI is running?

0.125.0

What subscription do you have?

gpt-5.4-mini / codex

Which model were you using?

gpt-5.4-mini / codex

What platform is your computer?

Local: Darwin arm64 (macOS M1 Pro) — works fine Remote: Linux x86_64 (Ubuntu 22.04, GCP VM t2d-60-cores, zone europe-west2-c) — broken

What terminal emulator and version are you using (if applicable)?

jetbrains , Terminal: GCP SSH terminal / iTerm2 SSH session

What issue are you seeing?

Codex CLI works perfectly on macOS. The moment I SSH into a Linux VM and run Codex, it permanently fails with 401 regardless of what I do:
unexpected status 401 Unauthorized: Incorrect API key provided: sk-proj-***_KEY
auth error code: invalid_api_key
url: https://api.openai.com/v1/responses
The key is valid — confirmed working on macOS simultaneously. The VM has no macOS Keychain, so Codex falls back to ~/.codex/auth.json. The problem is codex login --with-api-key does not reliably update auth.json — a background daemon reads the stale file before the login command writes to it, so the old or broken key persists permanently.

What steps can reproduce the bug?

Steps to reproduce:

SSH into a fresh Ubuntu Linux VM
Install Codex CLI: npm install -g @openai/codex
Set environment variable: export OPENAI_API_KEY="sk-proj-..."
Run: echo "$OPENAI_API_KEY" | codex login --with-api-key
Terminal confirms: Successfully logged in
Run: codex --dangerously-bypass-approvals-and-sandbox
Immediately get 401 using a different/stale key than what was just logged in

Everything attempted — all failed:

unset OPENAI_API_KEY and reset — no effect
export OPENAI_API_KEY="..." in shell — ignored by Codex
OPENAI_API_KEY="..." codex inline injection — ignored
codex login --with-api-key — confirms success but 401 persists
rm -rf ~/.codex and reinstall — daemon recreates auth.json with stale key
Manually overwriting ~/.codex/auth.json with new key JSON — temporarily works until daemon overwrites it again
security delete-generic-password -s "codex-cli" — N/A on Linux
Multiple fresh API keys created — all produce same 401 on VM, all work on Mac

Expected behavior:
Codex CLI should work on Linux VMs the same way it works on macOS. Since there is no Keychain on Linux, the env var OPENAI_API_KEY should be the authoritative credential source. codex login --with-api-key should atomically write to auth.json and no background daemon should be able to override it with a stale value.
Additional information:
This makes Codex completely unusable on cloud VMs — which is a core use case for compute-intensive workloads like ML training, molecular docking pipelines, and HPC tasks that cannot run on a local Mac. Claude Code handles this correctly by reading solely from the ANTHROPIC_API_KEY environment variable with no background daemon interference.
The VM in question is a GCP t2d-60-cores instance used for computational chemistry pipelines (AutoDock Vina, GNINA docking). Codex on the VM was specifically needed to orchestrate Python pipeline scripts that call GNINA binaries — work that cannot run locally on macOS because GNINA is Linux-only.
This is a critical gap in Codex's Linux/VM support. Please escalate to engineering.Sonnet 4.6Adaptive

What is the expected behavior?

_No response_

Additional information

Steps to reproduce:

SSH into a fresh Ubuntu Linux VM
Install Codex CLI: npm install -g @openai/codex
Set environment variable: export OPENAI_API_KEY="sk-proj-..."
Run: echo "$OPENAI_API_KEY" | codex login --with-api-key
Terminal confirms: Successfully logged in
Run: codex --dangerously-bypass-approvals-and-sandbox
Immediately get 401 using a different/stale key than what was just logged in

Everything attempted — all failed:

unset OPENAI_API_KEY and reset — no effect
export OPENAI_API_KEY="..." in shell — ignored by Codex
OPENAI_API_KEY="..." codex inline injection — ignored
codex login --with-api-key — confirms success but 401 persists
rm -rf ~/.codex and reinstall — daemon recreates auth.json with stale key
Manually overwriting ~/.codex/auth.json with new key JSON — temporarily works until daemon overwrites it again
security delete-generic-password -s "codex-cli" — N/A on Linux
Multiple fresh API keys created — all produce same 401 on VM, all work on Mac

Expected behavior:
Codex CLI should work on Linux VMs the same way it works on macOS. Since there is no Keychain on Linux, the env var OPENAI_API_KEY should be the authoritative credential source. codex login --with-api-key should atomically write to auth.json and no background daemon should be able to override it with a stale value.
Additional information:
This makes Codex completely unusable on cloud VMs — which is a core use case for compute-intensive workloads like ML training, molecular docking pipelines, and HPC tasks that cannot run on a local Mac. Claude Code handles this correctly by reading solely from the ANTHROPIC_API_KEY environment variable with no background daemon interference.
The VM in question is a GCP t2d-60-cores instance used for computational chemistry pipelines (AutoDock Vina, GNINA docking). Codex on the VM was specifically needed to orchestrate Python pipeline scripts that call GNINA binaries — work that cannot run locally on macOS because GNINA is Linux-only.
This is a critical gap in Codex's Linux/VM support. Please escalate to engineering.Sonnet 4.6Adaptive