#OpenClaw Gateway restart replaces ~/.codex/auth.json with API Key

12 messages · Page 1 of 1 (latest)

feral fox
#

every time i restart my openclaw gateway, the "~/.codex/auth.json" file gets overwriten by

"auth_mode": "apikey",
"OPENAI_API_KEY": "<real-api-key-here"
}

instead of using the existing file (my codex subscription)
is there an open github issue on this or a way to disable?

pearl folioBOT
limber prismBOT
#

Let me verify this against the docs and code so I don’t make up a config knob.

#

Short version: this exact rewrite does not look like OpenClaw’s own write path.

I checked the current docs/code:

So if ~/.codex/auth.json is ending up as:

{"auth_mode":"apikey","OPENAI_API_KEY":"..."}

the likely cause is that Codex CLI/app-server is seeing OPENAI_API_KEY in the gateway process env and switching itself to API key mode.

I did not find an exact OpenClaw issue for “gateway restart rewrites ~/.codex/auth.json to apikey”. Closest related:

#

What to do:

  1. Check whether your gateway service has OPENAI_API_KEY set.
  2. Remove/unset it from the gateway environment if you want to use your Codex subscription login.
  3. Check all env sources OpenClaw can load from: process env, cwd .env, ~/.openclaw/.env, config env, and env.shellEnv.enabled: https://docs.openclaw.ai/help/environment
  4. Make sure you’re using openai-codex/... or codex/..., not openai/...

Can you paste:

openclaw --version
openclaw models status

If models status shows OpenAI auth coming from OPENAI_API_KEY, that’s almost certainly the culprit. If it still happens with no OPENAI_API_KEY anywhere, I’d file a new OpenClaw bug.

feral fox
# 
❯ openclaw --version
openclaw models status
OpenClaw 2026.4.11 (769908e)

:lobster: OpenClaw 2026.4.11 (769908e)
   Your second brain, except this one actually remembers where you left things.

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : custom-glm/glm-5.1
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (1)   : GLM-5 -> custom-glm/glm-5.1
Configured models (1): custom-glm/glm-5.1

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (0): -
- brave effective=env:BSAK391Z...VunbyZAl | env=BSAK391Z...VunbyZAl | source=env: BRAVE_API_KEY
- custom-glm effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | custom-glm:default=826c3864...Q0WAfYKS
- deepgram effective=env:86a0a98b...c0e0c9ce | env=86a0a98b...c0e0c9ce | source=env: DEEPGRAM_API_KEY
- google effective=env:AIzaSyBF...YJJuXv5U | env=AIzaSyBF...YJJuXv5U | source=env: GEMINI_API_KEY
- kimi effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kimi-code:default=sk-kimi-...Lv0xqD6a | env=sk-kimi-...Lv0xqD6a | source=env: KIMICODE_API_KEY
- kimi-coding effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | kimi-code:default=sk-kimi-...Lv0xqD6a | env=sk-kimi-...Lv0xqD6a | source=env: KIMICODE_API_KEY
- openrouter effective=env:sk-or-v1...eb425192 | env=sk-or-v1...eb425192 | source=env: OPENROUTER_API_KEY
- perplexity effective=env:sk-or-v1...eb425192 | env=sk-or-v1...eb425192 | source=env: OPENROUTER_API_KEY
- zai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | zai:default=826c3864...Q0WAfYKS | env=826c3864...Q0WAfYKS | source=env: ZAI_API_KEY

OAuth/token status
- none
limber prismBOT
#

Yep, that output narrows it down a lot.

What it tells us:

  • Shell env: off, so this is not coming from your shell profile import
  • there is no openai / openai-codex auth profile in OpenClaw
  • your main model is custom-glm/glm-5.1, not a Codex/OpenAI model

So OpenClaw is not using Codex for the main agent here. Also, the Codex harness is off by default unless you explicitly use codex/* or force that runtime: https://docs.openclaw.ai/plugins/codex-harness

That means a plain gateway restart really should not need to touch ~/.codex/auth.json. I don’t know an existing OpenClaw issue for this exact case. The closest one is different, it is about syncing stale Codex auth into OpenClaw: https://github.com/openclaw/openclaw/issues/54506

My best guess now is:

  • the gateway service still has OPENAI_API_KEY somewhere in its env/config
  • something Codex-related is getting spawned on startup
  • Codex sees that key and rewrites ~/.codex/auth.json to API-key mode

Since shell env is off, check the remaining env sources from the docs:

#

https://docs.openclaw.ai/help/environment

Especially these on Linux:

  • process/service env
  • cwd .env
  • ~/.openclaw/.env
  • ~/.config/openclaw/gateway.env
  • env block inside ~/.openclaw/openclaw.json

Quick check:

rg -n "OPENAI_API_KEY" ~/.openclaw ~/.config/openclaw 2>/dev/null

If you want, also paste:

# 
openclaw status --all

and whether you have any codex, codex-cli, or ACP config in openclaw.json.

If restart alone repros this on 2026.4.11, with no Codex model configured, I’d file a new OpenClaw issue. That smells like a real bug, not intended behavior.

feral fox
#

ended up keeping the openclaw.json settings file, wiped everything else but that and the user profile and its now fixed

limber prismBOT
#

Nice, glad that fixed it. 🎉

That strongly suggests it was some stale state/env residue outside openclaw.json, not the config itself.

If it comes back, I’d check these first:

  • ~/.openclaw/.env
  • ~/.config/openclaw/gateway.env
  • any service-level OPENAI_API_KEY

And if you can reproduce it cleanly from there, that’s worth a GitHub issue.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.