OpenClaw Codex OAuth Repair: Restoring GPT Hands After 2026.6.1 Beta

Field report / OpenClaw 2026.6.1-beta.1

On 2 June 2026, our small team — Luna, Linda and Colet — repaired a broken GPT/Codex hands setup in OpenClaw after a beta update. The visible symptom looked like normal model routing trouble. The real fault was deeper: OpenClaw was using the wrong Codex OAuth credential/client path.

We started around 10:00 and finished with real proof around 14:47. This post explains what failed, what actually fixed it, and how other OpenClaw users can test their own AI tools before trusting them.

This is not a theory post. It is a real repair log from a working Linux/OpenClaw system, using backups, terminal checks, auth-profile inspection, gateway restarts, and live create/read/delete proof.

📋 TL;DR

After updating OpenClaw to 2026.6.1-beta.1, normal webchat and the GLM/default route worked, but GPT/OpenAI/Codex routes failed in real use. Some status checks looked fine, but real model calls failed with 401 or:

No credentials found for profile "openai-codex:<account>"

The key discovery was that the correct standalone Codex credential already existed at:

~/.codex/auth.json

That credential used the correct Codex OAuth client:

Correct Codex OAuth client ID verified internally — not published here.

Once the correct credential structure was imported into OpenClaw’s auth profile path and the auth cooldown/problem state was cleared, GPT-5.4-mini and GPT-5.5 Codex worked again. Real hands proof passed: create file, read it back, delete it.

🔍 What broke?

The beta update changed or shifted parts of the Codex/OpenAI provider naming and auth routing. The old working route involved a mix of openai, openai-codex, and codex. That created a messy failure pattern:

Gateway was running.
Normal webchat worked.
GLM/default model route worked.
Some model/status checks looked successful.
Real GPT/Codex calls still failed.
Some calls failed with missing credential errors.
Some calls failed with 401, meaning the Codex app-server rejected the token.

This is why model status alone is not proof. A model can appear listed, routed, or available, while still being unable to use real tools.

🧠 The wrong assumption

At first, the failure looked like an expired OpenAI OAuth token or a simple provider alias problem. Both were part of the picture, but not the real final cause.

The wrong assumption was:

If the OpenAI browser session is valid, the token should work for Codex.

That was false. A ChatGPT web token and a Codex token can belong to the same account but still be issued for different OAuth clients. Same user does not mean same token audience.

The Codex app-server expected the Codex client identity. A token from the wrong client could still look valid, but it failed in real Codex calls.

🎯 Root cause

The root cause was:

OpenClaw was importing or using the wrong Codex OAuth credential/client path after the 2026.6.1-beta.1 update.

The valid standalone Codex credential already existed at:

~/.codex/auth.json

The correct Codex client ID was verified internally:

Correct Codex OAuth client ID verified internally — not published here.

No token values should ever be printed, pasted into a chat, saved into a report, uploaded to a website, or given to another AI.

🛠️ What fixed it?

The repair was deliberately small:

Backed up the relevant OpenClaw auth/profile state.
Confirmed the standalone Codex CLI auth file existed.
Confirmed the credential source used the correct Codex OAuth client ID.
Imported/copied the correct credential structure into OpenClaw’s auth profile path.
Cleared auth cooldown/problem state caused by earlier failed calls.
Restarted the OpenClaw gateway.
Tested one small reply.
Tested one tiny hands action: create, read, delete.

The fix was not to keep patching random auth code. The fix was to prove the credential source and use the correct Codex credential path.

💾 Backup and Linux terminal lessons

This repair only stayed safe because we treated auth files and gateway state carefully. These are the habits that helped:

Back up files before editing auth/profile state.
Use stat, sha256sum, and cmp to prove file copies and ownership.
Use systemctl --user status openclaw-gateway to prove the gateway really restarted.
Use logs and real model calls, not just model lists.
Clear cooldown/problem state only after understanding the failed auth path.
Do not run repeated expensive model calls while debugging.
Do not paste auth files into AI chats. Ever.

Simple terminal tools matter. A careful cmp or sha256sum can save you from guessing whether the file you copied is actually the file now being used.

✅ Real proof checklist

For OpenClaw, “the model appears in the list” is not enough. Use this proof ladder:

Gateway is running.
Default route works.
Target model answers one cheap plain message.
Target model can create a small file.
Target model can read that file back.
Target model can delete the file.
The same proof works in the real user-facing channel, not only a test shell.

That final create/read/delete test proves the model route, auth, runtime and tools are all working together.

🤖 Tips for AI agents helping with this

If you ask another AI or agent to help debug OpenClaw/Codex auth, give it strict rules. Otherwise it may confidently inspect the wrong thing, print secrets, or test too much.

Tell it not to print token values.
Tell it not to paste auth JSON into chat.
Tell it not to run doctor --fix without human approval.
Tell it not to delete or rewrite auth profiles without backup.
Tell it to check ~/.codex/auth.json first.
Tell it to separate model status from real tool proof.
Tell it to stop after one cheap reply and one tiny hands proof.

Good AI debugging is not “try everything”. Good AI debugging is: prove the layer, change one thing, test the smallest real action, then document what actually happened.

🚫 What not to do

Do not run openclaw doctor --fix as a shortcut.
Do not assume a browser ChatGPT token is valid for Codex.
Do not trust model status alone.
Do not create duplicate memory or conflicting repair notes.
Do not directly write shared brain/memory stores from a sandbox agent.
Do not run repeated model tests under someone else’s quota without approval.
Do not expose tokens, cookies, OAuth codes or full auth JSON.

🧭 Recovery checklist

If your OpenClaw GPT/Codex hands break after an update, work through this:

Stop repeated model testing.
Check gateway status.
Check whether GLM/default route still works.
Check provider naming: codex, openai-codex, openai.
Check whether ~/.codex/auth.json exists.
Check OpenClaw auth profiles without printing secrets.
Check auth-state/cooldown state.
Check gateway logs for real model-call failures.
Do not run doctor --fix unless a human approves it.
Make backups before any auth-profile edit.
Restart gateway after auth changes.
Test one cheap reply.
Test one tiny create/read/delete action.
Write a repair note so the next update does not become archaeology with keyboards.

🔗 Related repair

This repair follows our earlier OpenClaw field report about a missing provider ID in the Codex harness:

Silent Failure: How a Missing Provider ID Broke GPT-5.5 Hands in OpenClaw — And How We Traced It

Need help with OpenClaw, Codex or AI tools?

WM IT Solutions helps with practical AI operations: OpenClaw setup, Linux-based troubleshooting, model routing, tool access, automation, backup planning and real-world proof testing. If your AI can talk but cannot do, or if your model routing looks alive but tools fail, we can help trace it properly.

Get in touch →

Published: 2 June 2026 | Team: Luna, Linda and Colet | Category: AI Operations, OpenClaw, Linux troubleshooting

Safety note: This article deliberately does not include token values, full auth JSON, cookies, OAuth codes or private keys.

OpenClaw 2026.6.1 Codex OAuth Repair: How We Restored GPT Hands After a Beta Update