Help Needed: 5-Agent Swarm crashing Codex OAuth (401 refresh_token_reused). Is there a concurrency w

[cyan shell]

Hey everyone, I'm running into a wall trying to get a 5-agent swarm running on my ChatGPT Plus subscription via the openai-codex provider. I know the standard API key solves this, but I've seen mentions of people getting multi-agent setups working on the Codex tier and I'm trying to figure out how to bypass this race condition.

My Environment:

OS: Windows (PowerShell)

OpenClaw Version: 2026.4.26

Model Pipeline: "openai-codex/gpt-5.5"

Architecture: 5 custom agents (Atlas, Axon, Nova, Nexis, Lumi) connected to 6 specific Discord channels via the openclaw.json bindings.

The Core Issue:
Whenever my swarm boots up or multiple agents are triggered, they all attempt to grab the browser OAuth token at the same time. One agent successfully negotiates the session (Default Agent), rotating the token, and the others instantly crash the gateway because the token is invalidated.

The terminal throws this exact error from OpenAI:

[openai-codex] Token refresh failed: 401
"message": "Your refresh token has already been used to generate a new access token. Please try signing in again."
"code": "refresh_token_reused"

[scarlet mist]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[cyan shell]

This cascades into the gateway throwing Model login failed on the gateway for openai-codex, and eventually, OpenClaw panics and auto-restores an old config backup.

Troubleshooting Steps Taken (None have worked):

Update & Doctor: Updated to .26 and ran openclaw doctor --fix. This actually started the loop by wiping the initial stable state.

Deep Cache Nuke: Stopped the gateway and physically deleted the root credentials folder, the global workspace .openclaw folder, and every hidden .openclaw state folder inside the individual agent directories to ensure a 100% sterile environment.

Manual Auth: Used openclaw models auth login --provider openai-codex and manually passed the localhost:1455 callback URL.

The "Staggered Boot" Strategy: Tried to serialize the token request. We set the JSON to run only the default agent. Booted the gateway, authenticated, and successfully pinged the agent in Discord. Once the session was stable, I hot-reloaded the openclaw.json with the remaining 4 agents added back in.

    Result: The second I pinged one of the newly loaded agents, it tried to refresh the token, triggered the 401 reused error, and crashed the backend again.

My Question:
If you are running a concurrent multi-agent swarm on the openai-codex provider (ChatGPT Plus) without using a paid/stateless sk- API key, how are you handling the token rotation? Is there a way to force the agents to share the active session cookie without individually requesting a refresh, or a way to serialize their backend requests so they don't trigger OpenAI's hijack block?

Keep in mind i had all 5 agents working fine on OpenClaw .15 and GPT-5.4

Any insight would be hugely appreciated!

[hollow topaz]

That’s a real OAuth race, not a Discord binding issue.

refresh_token_reused means multiple agents are trying to spend the same rotating Codex/ChatGPT OAuth refresh token. OpenClaw stores auth per agent in each agentDir, and copied/shared auth-profiles.json files can collide when the token expires. OAuth docs also call out that refresh flows can invalidate older tokens. (docs.openclaw.ai)

Best options:

1. Most stable: use an OpenAI API key for the 5-agent swarm.
2. If staying on ChatGPT/Codex OAuth: avoid five isolated agents sharing one copied OAuth credential. Prefer one coordinator agent + sessions/subagents, or separate real accounts/profiles.
3. Short-term recovery: stop the gateway, re-auth, then restart:

openclaw gateway stop
openclaw models auth login --provider openai-codex
openclaw doctor
openclaw gateway restart

If you auth per configured agent, the command shape is:

openclaw models auth --agent Atlas login --provider openai-codex

…but logging five agents into the same ChatGPT account may just recreate the rotation problem.

Also: current docs say new configs should prefer canonical openai/gpt-5.5 with openai-codex auth; openai-codex/* is now legacy-compatible naming. (docs.openclaw.ai)

If this still crashes on 2026.4.26, please file a GitHub issue with openclaw status --all and the redacted OAuth error. This sounds like exactly the kind of concurrency bug maintainers need a repro for.

This shouldn’t require “sharing cookies.” The intended shape is:

• one Gateway / one $OPENCLAW_STATE_DIR
• separate agentDirs
• each agent has its own auth-profiles.json
• if sharing one Codex OAuth account, copy the same auth-profiles.json into each agent dir
• OpenClaw should serialize refreshes with the OAuth refresh lock

Docs: https://docs.openclaw.ai/concepts/multi-agent and https://docs.openclaw.ai/concepts/oauth

What I would try next on Windows:

openclaw gateway stop
openclaw models auth login --provider openai-codex

Then copy the default agent’s auth profile to the other agents’ agentDir, not workspace dir:

Copy-Item "$env:USERPROFILE\.openclaw\agents\main\agent\auth-profiles.json" "$env:USERPROFILE\.openclaw\agents\Atlas\agent\auth-profiles.json" -Force
Copy-Item "$env:USERPROFILE\.openclaw\agents\main\agent\auth-profiles.json" "$env:USERPROFILE\.openclaw\agents\Axon\agent\auth-profiles.json" -Force
Copy-Item "$env:USERPROFILE\.openclaw\agents\main\agent\auth-profiles.json" "$env:USERPROFILE\.openclaw\agents\Nova\agent\auth-profiles.json" -Force
# etc

Then:

openclaw doctor
openclaw gateway restart
openclaw agents list --bindings

Avoid doing five separate models auth login --agent ... logins into the same ChatGPT account — each OAuth login/refresh can rotate the token and invalidate the others.

If that exact setup still produces refresh_token_reused on 2026.4.26, I’d treat it as a bug/regression and file it here with openclaw status --all, openclaw agents list --bindings, and redacted logs: https://github.com/openclaw/openclaw/issues

Do not paste auth-profiles.json publicly — it contains live OAuth material.

[cyan shell]

[Bug] v2026.4.26: OAuth Refresh Lock Fails in Multi-Agent Swarm (401 refresh_token_reused)
Description

In version 2026.4.26, the internal OAuth refresh lock fails to serialize token refresh requests when running a multi-agent swarm sharing a single ChatGPT Plus account (openai-codex provider). Even when strictly following the "intended shape" architecture (mirroring a single auth-profiles.json across separate agent directories), concurrent agent activity bypasses the lock. This causes multiple agents to attempt a token refresh simultaneously, resulting in OpenAI instantly invalidating the session with a 401 refresh_token_reused error.
Environment

OS: Windows 11 (PowerShell)

OpenClaw Version: 2026.4.26

Provider: openai-codex (ChatGPT Plus OAuth)

Model Routing: openai/gpt-5.5 canonical mapping

Steps to Reproduce

Purge Cache: Stopped the gateway and completely deleted the root credentials folder, the global workspace .openclaw folder, and all hidden .openclaw state folders inside the individual agent directories to ensure a sterile environment.

Generate Master Token: Ran openclaw models auth login --provider openai-codex and completed the browser OAuth handshake.

Mirror Auth Profile: Used PowerShell to strictly copy the resulting auth-profiles.json into all 5 isolated agent directories (Atlas, Axon, Nova, Nexis, Lumi).

Configure JSON: Updated openclaw.json to use canonical naming (openai/gpt-5.5) and mapped the auth routing at the bottom:

JSON

"auth": {
"profiles": {
"openai-codex:[REDACTED_EMAIL]": {
"provider": "openai-codex",
"mode": "oauth"
}
},
"routing": {
"openai": "openai-codex:[REDACTED_EMAIL]"
}
}

Boot Gateway: Ran openclaw doctor (archived orphan transcripts, declined forced token refresh), then openclaw gateway restart.

Trigger Swarm: Sent a prompt to one of the agents via Discord bindings.

Expected Behavior

OpenClaw's internal OAuth refresh lock recognizes that all 5 agents are sharing identical token footprints via their mirrored auth-profiles.json files, serializes the refresh requests, and safely rotates the token for the entire swarm without causing a race condition.
Actual Behavior

The gateway boots cleanly and connects to Discord (sessions.subscribe succeeds). However, upon receiving a prompt, the lock fails to serialize the requests. Multiple agents attempt to spend the rotating token, triggering a hard block from OpenAI's servers and crashing the connection.
Redacted Logs
Plaintext

21:21:47 [openai-codex] Token refresh failed: 401 {
"error": {
"message": "Your refresh token has already been used to generate a new access token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "refresh_token_reused"
}
}
21:21:47 [diagnostic] lane task error: lane=session:agent:nova:discord:channel:[REDACTED] durationMs=238566 error="Error: OAuth token refresh failed for openai-codex: Failed to refresh OpenAI Codex token. Please try again or re-authenticate."
21:21:47 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openai-codex/gpt-5.5 candidate=openai-codex/gpt-5.5 reason=auth next=none detail=OAuth token refresh failed

Diagnostics

openclaw status --all output:
Plaintext

[Paste the output of this command here before submitting]

openclaw agents list --bindings output:
Plaintext

[Paste the output of this command here before submitting]

Additional Context

This appears to be a regression or a broken lock mechanism specifically in .26. Staggered booting (starting the gateway with one agent, authenticating, and hot-reloading the JSON with the remaining agents) also results in the exact same 401 crash the moment a newly loaded agent is pinged. The only current workaround is dropping to a single-agent architecture or abandoning OAuth for a paid stateless API key.

[hollow topaz]

Yep, this is now issue-worthy.

Two important notes:

1. Small correction: for Codex OAuth on the normal PI runner, the model ref should still be:

openai-codex/gpt-5.5

openai/gpt-5.5 is direct OpenAI API-key routing unless paired with agentRuntime.id: "codex". Docs: https://docs.openclaw.ai/concepts/model-providers

2. The refresh lock should serialize by provider + profileId under the shared state dir. If it’s still racing, likely causes are:
   • agents are not actually using the same $OPENCLAW_STATE_DIR
   • agents are selecting different profile IDs that point at copied token material
   • the openai/gpt-5.5 / runtime mapping is sending some turns down a different auth path
   • Windows file-lock behavior is regressing here

For the GitHub issue, include:

openclaw status --all
openclaw gateway status
openclaw agents list --bindings
openclaw models status --agent Atlas --json
openclaw models status --agent Axon --json

And include the non-secret parts of config: agents, auth.order, model defaults, and provider blocks. Do not paste auth-profiles.json.

If you want one more quick sanity check: make sure every agent is selecting the exact same openai-codex:<profile> profile ID, not just copied token contents under different profile names.

I think your repro has one config problem that may be muddying the bug:

auth.routing

doesn’t look like a valid auth config key. The supported knobs are auth.profiles + auth.order, and the provider key should be openai-codex, not openai.

Try replacing that block with:

{
  auth: {
    profiles: {
      "openai-codex:[REDACTED_EMAIL]": {
        provider: "openai-codex",

        mode: "oauth",
      },
    },
    order: {
      "openai-codex": ["openai-codex:[REDACTED_EMAIL]"],
    },
  },
  agents: {
    defaults: {
      model: {
        primary: "openai-codex/gpt-5.5",
      },
    },
  },
}

Docs: https://docs.openclaw.ai/concepts/model-failover and https://docs.openclaw.ai/concepts/model-providers

Also: the lock is keyed by provider + profileId, not by “identical token footprint”, so the issue should say all agents have the same profile id openai-codex:[email].

For extra certainty, pin the order per agent too:

openclaw models auth order set --provider openai-codex --agent Atlas openai-codex:[REDACTED_EMAIL]
openclaw models auth order set --provider openai-codex --agent Axon openai-codex:[REDACTED_EMAIL]
openclaw models auth order set --provider openai-codex --agent Nova openai-codex:[REDACTED_EMAIL]

Then check:

openclaw models status --agent Atlas --probe --probe-provider openai-codex

openclaw models status --agent Nova --probe --probe-provider openai-codex

If it still races after that, yep, file it as a Windows/multi-agent OAuth lock regression.

Yep — if this still happens after auth.order is pinned and all agents share the same openai-codex:<profile> id, this is a legit bug report.

Before submitting, I’d clean up two things:

1. Replace the placeholder with real output:

openclaw status --all
openclaw agents list --bindings
openclaw models status --agent Atlas --json
openclaw models status --agent Nova --json

2. Word expected behavior as:

OpenClaw should serialize refresh by provider + profileId (openai-codex:[email]) across agent dirs.

Not “identical token footprint” — the lock isn’t supposed to infer token equality.

Also include that .15 + GPT-5.4 worked and .26 + GPT-5.5 regressed. That’s useful.

There isn’t a supported “share active browser cookie” workaround here. For now, the realistic workarounds are exactly what you found: single-agent/coordinator architecture, API key, or temporarily pinning to the last version that worked for you.

Docs refs: https://docs.openclaw.ai/concepts/oauth and https://docs.openclaw.ai/concepts/multi-agent

[cyan shell]

Got the update from my Git bug report on why it's happening. Looks like the patch will be included in the next update

I was mirroring the files correctly, but the software was designed to "shadow" the main store. Essentially, my agents were looking at her own local copy of the token, seeing it was old, and trying to refresh it—ignoring the fact that the default agent had already done the work. The software was ignoring the fresh main credentials and using "stale mirrored child-store shapes." Steipete has now rewritten the engine so secondary agents will "read-through" the main agent's credentials instead of keeping their own copies.

The fix is currently on the main branch of GitHub, but it hasn't been pushed to the stable npm or pnpm release yet.

https://github.com/openclaw/openclaw/issues/74055

[hollow topaz]

Nice, thanks for looping back. That diagnosis makes sense: stale per-agent auth snapshots + one-time refresh tokens is exactly the nasty combo that would cause refresh_token_reused.

Until the npm/pnpm release lands, safest path is still:

• keep Codex OAuth to one active agent, or
• use stateless API-key auth for multi-agent swarms

Once you update past 2026.4.26, re-auth once, restart the gateway, and test the swarm again. Glad this got pinned down. 🦐