WMIT Solutions

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

Luna WMIT — Tue, 02 Jun 2026 13:52:38 +0000

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:"

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.

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

Luna WMIT — Fri, 29 May 2026 18:13:21 +0000

Bug Report / OpenClaw 5.27

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

A single incomplete Set in a plugin’s harness file silently disabled all GPT-5.5 tool execution. No error message. No warning. Just silent fallback to a weaker model. Here is the full trace, the fix, and a template you can use to test your own OpenClaw setup before you rely on it.

#openclaw #gpt55 #bugreport #aiops #codex #aihands #debugging #mismoosh #wmitsolutions

📋 TL;DR

OpenClaw 5.27’s built-in Codex plugin bundles its own copy of harness.js with a hardcoded Set of only one provider ID: "codex". Any request using openai-codex/gpt-5.5 or openai/gpt-5.5 silently failed because the provider was not recognised. The core OpenClaw harness had the full set — but the plugin’s bundled copy overrode it.

Result: GPT-5.5 could think but could not use tools. No error, no log, just silent fallback. Our team of three spent six hours tracing through five layers of bundled JavaScript to find the root cause.

🔍 The Bug

OpenClaw routes AI model requests through a “harness” that determines whether a model is allowed to use the Codex runtime (which gives the model hands — shell execution, file access, browser control, etc.). The harness checks if the model’s provider ID is in an allowed set.

The Codex plugin (@openclaw/codex) bundles its own harness.js at:

~/.openclaw/extensions/codex/dist/harness.js

Inside that file, the default provider set was:

const DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex"]);

Only "codex". Missing:

"openai-codex" — the actual provider ID used by GPT-5.5 via Codex
"openai" — the standard OpenAI provider

The core OpenClaw harness file (dist/harness-CyCnEyfS.js) had the correct full set — but the plugin’s bundled copy was loaded instead, completely overriding it.

🧭 How We Found It

This was not a simple grep job. The bug sat behind five layers of bundled, minified JavaScript. Here is the actual trace path our team followed:

Layer 1: "provider is not one of: codex" error in runtime

  → Layer 2: runtime-plugin-Cfk1SXkA.js — fallback path rejects provider

    → Layer 3: harness-CyCnEyfS.js — has full Set but never loaded

      → Layer 4: Plugin system loads extension harness instead of core

        → Layer 5: ~/.openclaw/extensions/codex/dist/harness.js

          → Line: DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex"])

            → 🎯 ROOT CAUSE: Missing "openai-codex" and "openai"

We spent time patching layers 2 and 3 first — adding the missing IDs to the core harness and the runtime plugin. Those patches had zero effect because the plugin system loaded the extension’s own copy at layer 5.

A second AI agent (running on a separate sandboxed instance) independently identified the ACP protocol mismatch at layer 1. The two findings converged at layer 5 — the plugin harness.

🔧 The Fix

Change the default provider set in the plugin’s harness to include all three provider IDs:

// BEFORE (broken — only "codex")

const DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex"]);

// AFTER (fixed — all three providers) const DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex","openai-codex","openai"]);

⚠️ Important: This patch is local only. Every npm update -g openclaw or npm update -g @openclaw/codex will overwrite this file. You must re-apply the patch after every update.

Also clear the V8 compile cache after patching: rm -rf /tmp/node-compile-cache/openclaw/

📦 Copy-Paste Bug Report Template

Use this template to report OpenClaw harness bugs. Fill in the blanks and submit to the OpenClaw GitHub issues or your internal tracker.

---

title: "OpenClaw Codex harness DEFAULT_CODEX_HARNESS_PROVIDER_IDS missing providers"

severity: high

component: @openclaw/codex (extension harness)

affected_versions: ">=5.27-beta.1"

date_reported: 2026-05-29

reporter: WM IT Solutions / Mismoosh Ltd

---
## Summary

The bundled harness.js in the @openclaw/codex extension

only includes "codex" in DEFAULT_CODEX_HARNESS_PROVIDER_IDS.

Requests using "openai-codex" or "openai" providers

silently fail and fall back to a non-hands model.
## Impact

- GPT-5.5 via openai-codex/gpt-5.5 cannot use tools

- No error message is shown to the user

- Silent fallback to weaker model without notification

- Plugin harness overrides core harness silently
## Root Cause

File: ~/.openclaw/extensions/codex/dist/harness.js

Line: DEFAULT_CODEX_HARNESS_PROVIDER_IDS = new Set(["codex"])

Missing: "openai-codex", "openai"
## Fix

Change to: new Set(["codex","openai-codex","openai"])
## Reproduction

1. Configure model: openai-codex/gpt-5.5 with agentRuntime: "codex"

2. Send any tool-use request

3. Observe: tools not available, silent fallback occurs
## Workaround

Patch the harness.js file manually after every update.

---

📋 Click the box above to select all. Paste into GitHub issues, internal trackers, or email.

🤖 How AI Can Test This Before You Rely On It

If you are running OpenClaw with any AI model — whether it is a cloud model like GPT-5.5 or Gemini, a local model via Ollama, or a specialised agent like Hermes — test tool access before you trust it. Here is how:

# Step 1: Check which model is active

openclaw status
# Step 2: Test if the model has hands (tool access)

# In your OpenClaw chat, ask:

#   "List your available tools"

#   "Run: echo hello"

#   "Read a file from the workspace"
# Step 3: If tools are missing or commands fail silently:

# Check the harness provider set:

grep -r "DEFAULT_CODEX_HARNESS_PROVIDER_IDS"

  ~/.openclaw/extensions/codex/dist/harness.js
# Step 4: If the Set only has "codex":

# Patch it:

sed -i 's/new Set(["codex"])/new Set(["codex","openai-codex","openai"])/'

  ~/.openclaw/extensions/codex/dist/harness.js
# Step 5: Clear V8 compile cache and restart

rm -rf /tmp/node-compile-cache/openclaw/

systemctl --user restart openclaw-gateway.service
# Step 6: Re-test

# Ask the model again: "List your available tools"

Using a cloud AI to debug: You can ask GPT-5.5, Gemini, or Claude to check your OpenClaw harness configuration by providing them with the output of openclaw status and the contents of your harness files.

Using OpenClaw itself: Spawn a test subagent with a simple tool-use task. If it completes, hands work. If it falls back or produces no tool calls, the harness is blocking.

Using Hermes or similar sandboxed agents: Run an isolated test outside OpenClaw’s tool chain. If the same model works in a sandbox but not through OpenClaw, the problem is in the harness/routing layer, not the model.

⏱️ The Six-Hour Trace

A team of three — a senior systems engineer, a healthcare and operations specialist, and an AI operations agent — traced this bug from symptom to root cause in six hours on 28-29 May 2026.

The first two hours went to patching the wrong layers. The core harness file looked right. The runtime plugin looked fixable. Neither patch worked. The AI agent independently identified the ACP protocol mismatch — a different symptom of the same root cause — and that clue pushed the investigation to the extension plugin layer.

Hours three through five were spent reading bundled, minified JavaScript across five files, mapping call paths, and understanding how the extension system overrides the core harness.

Hour six: the one-line fix. Then two hours of verification, defensive patching, and documentation. Total: eight hours from first symptom to verified fix. The actual fix was one line. Finding it took everything we had.

⚠️ Other Bugs Found in 5.27

While tracing the harness bug, we found and patched two additional issues:

Bug 2 — ACP protocol detection mismatch

File: dist/runtime-ClyQRfts.js
The function isCodexAcpCommand() only recognised @zed-industries/codex-acp but the built-in Codex uses @agentclientprotocol/codex-acp. Patched to recognise both.

Bug 3 — Gemini CLI flag change

File: dist/cli-backend-BtKnTf6Z.js
Gemini CLI v0.37.0 dropped the --skip-trust flag and replaced it with --yolo. OpenClaw was still passing the old flag. Patched to use the new one.

📝 Key Lessons

Plugin code overrides core code. If an extension bundles its own copy of a core module, patching the core version does nothing. Always check extension directories first.
Silent failures are the worst failures. No error message, no log entry — just a weaker model taking over without telling you. Test tool access explicitly after every update.
Two heads are better than one. An independent AI agent caught a symptom we initially dismissed. Converging from two different angles found the root cause faster than either angle alone.
Local patches need maintenance. Every npm update will overwrite these fixes. Document what you patched, where, and why. Re-apply after every update.
Test before you trust. After any OpenClaw update, run a simple tool-use test. One minute of testing beats six hours of debugging.

Need Help With AI Debugging?

WM IT Solutions provides specialist AI operations support — from OpenClaw setup and debugging to custom AI agent deployment, cloud model integration, and hands-on troubleshooting. If your AI stack is silently failing or your tools are not working as expected, we can help trace and fix it.

Get in touch →

Published: 29 May 2026 | Author: Mismoosh Ltd / WM IT Solutions | Category: Bug Report, AI Operations

OpenClaw is open-source software. This bug report is provided to help the community. The patches described are local workarounds until official fixes are released. Always test after applying any patch.

🔧 Full Repair Board Available

This blog post is the story. For the full diagnostic and repair resource — with bug report template, AI investigation prompt, proof checklist, and patch instructions — see the dedicated repair board:

Open Repair Board →

Seagate Storage Surge Vol. 3: Fresh storage arrivals built for bigger workflows

mismooshltd — Wed, 25 Mar 2026 14:25:20 +0000

News / Storage Drop

Seagate Storage Surge Vol. 3: Fresh storage arrivals built for bigger workflows

Need more room without the endless spec maze? This drop packs ten fresh storage moves built for backups, big media folders, calmer archives and smoother day-to-day performance. Tap any card for the full product trail in the shop.

#seagate #storageupgrade #backupdrives #creatorstorage #workstationstorage

Browse the shop

Storage pick

Seagate Enterprise ST4000NM027B internal hard drive 4 TB 7200 RPM 256 MB 3.5" SAS

Model: ST4000NM027B

Fast read: Exos • 4 TB • 7200 RPM • 256 MB • 3.5"

A confident move for files, backups and always-on storage jobs. This Seagate pick is designed to make the day feel smoother, faster or more dependable when reliability matters more than hype.

With Exos, 4 TB and 7200 RPM in the mix, it turns the spec sheet into something more useful: better flow, cleaner workflow and less friction every time you reach for it.

Sets you up to keep important files close, organised and easy to access.
Fits naturally into backup plans, creator kits, archives or game libraries.
A strong shortlist move when storage needs to feel purposeful, not random.

#DataBackup #WorkstationReady #AlwaysOnStorage

WMIT Solutions

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

📋 TL;DR

🔍 What broke?

🧠 The wrong assumption

🎯 Root cause

🛠️ What fixed it?

💾 Backup and Linux terminal lessons

✅ Real proof checklist

🤖 Tips for AI agents helping with this

🚫 What not to do

🧭 Recovery checklist

🔗 Related repair

Need help with OpenClaw, Codex or AI tools?

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

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

📋 TL;DR

🔍 The Bug

🧭 How We Found It

🔧 The Fix

📦 Copy-Paste Bug Report Template

🤖 How AI Can Test This Before You Rely On It

⏱️ The Six-Hour Trace

⚠️ Other Bugs Found in 5.27

📝 Key Lessons

Need Help With AI Debugging?

🔧 Full Repair Board Available

Seagate Storage Surge Vol. 3: Fresh storage arrivals built for bigger workflows

Seagate Storage Surge Vol. 3: Fresh storage arrivals built for bigger workflows

Seagate Enterprise ST4000NM027B internal hard drive 4 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST8000NM017B internal hard drive 8 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Enterprise ST8000NM018B internal hard drive 8 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST8000NM019B internal hard drive 8 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Enterprise ST8000NM020B internal hard drive 8 TB 7200 RPM 256 MB 3.5" SAS

Seagate Exos M internal hard drive 28 TB 7200 RPM 512 MB 3.5" Serial ATA

Seagate Exos M internal hard drive 30 TB 7200 RPM 512 MB 3.5" Serial ATA

Seagate Exos X24 internal hard drive 16 TB 7200 RPM 512 MB 3.5" SAS

Seagate Exos X24 internal hard drive 16 TB 7200 RPM 512 MB 3.5" SAS

Seagate Exos X24 internal hard drive 16 TB 7200 RPM 512 MB 3.5" Serial ATA III

Seen your next move?

Seagate Storage Surge Vol. 2: Capacity picks for creators, gamers and always-on setups

Seagate Storage Surge Vol. 2: Capacity picks for creators, gamers and always-on setups

Seagate Enterprise ST2000NM000B internal hard drive 2 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Enterprise ST2000NM001B internal hard drive 2 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST2000NM017B internal hard drive 2 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Enterprise ST2000NM018B internal hard drive 2 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST4000NM000B internal hard drive 4 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Enterprise ST4000NM001B internal hard drive 4 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST4000NM006B internal hard drive 4 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Enterprise ST4000NM007B internal hard drive 4 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST4000NM025B internal hard drive 4 TB 7200 RPM 256 MB 3.5" SAS

Seagate Enterprise ST4000NM026B internal hard drive 4 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seen your next move?

Seagate Storage Surge Vol. 1: Hard drives ready for backup, builds and big files

Seagate Storage Surge Vol. 1: Hard drives ready for backup, builds and big files

Seagate Barracuda 2.5" internal hard drive 1 TB 5400 RPM 128 MB 2.5" Serial ATA III

Seagate Barracuda 2.5" internal hard drive 2 TB 5400 RPM 128 MB 2.5" Serial ATA III

Seagate Barracuda 2.5" internal hard drive 500 GB 5400 RPM 128 MB 2.5" Serial ATA III

Seagate Barracuda ST1000DM014 internal hard drive 1 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Barracuda ST2000DM008 internal hard drive 2 TB 7200 RPM 256 MB 3.5" Serial ATA III

Seagate Barracuda ST3000DM007 internal hard drive 3 TB 5400 RPM 256 MB 3.5" Serial ATA III

Seagate Barracuda ST4000DM004 internal hard drive 4 TB 5400 RPM 256 MB 3.5" Serial ATA III

Seagate Basic external hard drive 2 TB 2.5" 2.0 Silver

Seagate Basic external hard drive 5 TB 2.5" 3.2 Gen 1 (3.1 Gen 1) Silver

Seagate Enterprise Exos 7E10 6TB 512E/4kn SATA SED internal hard drive 7200 RPM 256 MB 3.5" Serial ATA III

Seen your next move?

Kingston Memory Mode Vol. 5: More headroom for work, play and power users

Kingston Memory Mode Vol. 5: More headroom for work, play and power users

Kingston Technology KSM32RS4/32HCR memory module 32 GB 1 x 32 GB DDR4 3200 MT/s 288-pin DIMM ECC

Kingston Technology KSM32RS4/32MFR memory module 32 GB 1 x 32 GB DDR4 3200 MT/s 288-pin DIMM ECC

Kingston Technology KSM32SED8/32HD memory module 32 GB 1 x 32 GB DDR4 3200 MT/s 260-pin SO-DIMM ECC

Kingston Technology KSM32SES8/16HC memory module 16 GB DDR4 3200 MT/s 260-pin SO-DIMM ECC

Kingston Technology KTH-PL432/64G memory module 64 GB 1 x 64 GB DDR4 3200 MT/s 288-pin DIMM ECC

Kingston Technology ValueRAM memory module 16 GB 1 x 16 GB DDR4 260-pin SO-DIMM

Kingston Technology ValueRAM memory module 16 GB 1 x 16 GB DDR4 288-pin DIMM

Kingston Technology ValueRAM memory module 16 GB 1 x 16 GB DDR4 288-pin DIMM

Kingston Technology ValueRAM memory module 16 GB 1 x 16 GB DDR4 3200 MT/s 260-pin SO-DIMM

Kingston Technology ValueRAM memory module 16 GB 1 x 16 GB DDR4 3200 MT/s 288-pin DIMM

Seen your next move?

Kingston Memory Mode Vol. 4: RAM upgrades that keep creative sessions smooth