#model login failed on one of the agents (rest of them work fine)

22 messages · Page 1 of 1 (latest)

sage mica
#

I get the following on one of the agents, the rest of them continue to work just fine. Any ideas?

⚠️ Model login failed on the gateway for openai-codex. Please try again. If this keeps happening, re-auth with openclaw models auth login --provider openai-codex.

left ingotBOT
#

Yep, that message is specifically an openai-codex OAuth refresh failure on the gateway, not a generic model crash.

Since only one agent is failing, I'd strongly suspect that agent's own auth state or auth order. Auth is per-agent, stored in:

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

First, what does openclaw --version show?

Then on the gateway host, check the failing agent with:

openclaw models status --agent <failing-agent-id> --probe --probe-provider openai-codex
openclaw models auth order get --provider openai-codex --agent <failing-agent-id>
openclaw doctor

Most likely causes:

#
  • stale/expired Codex OAuth for that one agent
  • auth order pinned to a bad openai-codex:* profile
  • old models.providers.openai-codex transport overrides shadowing the built-in Codex OAuth path
  • wrong or empty auth-profiles.json for that agent

If the probe shows expired / invalid_grant / re-auth required, run:

openclaw models auth login --provider openai-codex

If this is happening inside the chat session itself, /model status is also useful, it shows which agent and auth file that thread is actually using.

Docs:
https://docs.openclaw.ai/cli/models
https://docs.openclaw.ai/concepts/oauth
https://docs.openclaw.ai/gateway/doctor

sage mica
left ingotBOT
#

Nice, 2026.4.14 looks current enough, so this doesn’t smell like an old known-bad build.

Next step is the agent-specific auth probe. On the gateway host, please run:

openclaw models status --agent <failing-agent-id> --probe --probe-provider openai-codex
openclaw models auth order get --provider openai-codex --agent <failing-agent-id>
openclaw doctor

If you don’t know the agent id yet, either:

  • run /model status in the failing chat, or
  • run openclaw agents list --bindings

What I’m looking for in the output:

  • invalid_grant / re-auth required → that agent’s Codex OAuth is dead
#
  • excluded_by_auth_order or weird pinned profile order → clear/fix auth order
  • doctor warning about models.providers.openai-codex → stale legacy override shadowing Codex OAuth
  • missing/empty auth store → wrong auth-profiles.json for that agent

Paste those outputs and I should be able to tell which bucket it’s in pretty quickly.

sage mica
#

how do I login per agent?

left ingotBOT
#

Yeah, the slightly annoying bit is: models auth login does not take --agent.

Per-agent login is done by pointing the command at that agent’s agentDir:

OPENCLAW_AGENT_DIR=~/.openclaw/agents/<agentId>/agent \
  openclaw models auth login --provider openai-codex

Example for an agent called work:

OPENCLAW_AGENT_DIR=~/.openclaw/agents/work/agent \
  openclaw models auth login --provider openai-codex

Then verify it with:

#
openclaw models status --agent work --probe --probe-provider openai-codex

A couple of notes:

  • each agent has its own auth store at ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
  • models status / models auth order ... support --agent, but models auth login currently doesn’t
  • don’t reuse one agentDir across multiple agents

If you want, paste the failing agent id and I can give you the exact command for that one.

Docs:
https://docs.openclaw.ai/concepts/multi-agent
https://docs.openclaw.ai/concepts/oauth
https://docs.openclaw.ai/cli/agents
https://docs.openclaw.ai/cli/models

sage mica
left ingotBOT
#

Yep, that’s basically the smoking gun.

ok expires in 0m means the profile exists, but the access token is effectively at expiry right now. So the next request has to refresh it, and that refresh is what’s failing.

I’d re-auth that specific agent now:

OPENCLAW_AGENT_DIR=~/.openclaw/agents/<agentId>/agent \
  openclaw models auth login --provider openai-codex

Then verify with:

openclaw models status --agent <agentId> --probe --probe-provider openai-codex
#

So the short version is:

  • ok = the auth profile is present
  • expires in 0m = token is on the edge / effectively expired
  • your runtime error = refresh/login path is failing for that agent

If it still fails right after re-auth, paste:

  • openclaw models status --agent <agentId> --probe --probe-provider openai-codex
  • openclaw doctor

At that point I’d suspect a stale models.providers.openai-codex override or some per-agent auth-store weirdness.

sage mica
#

🦞 OpenClaw 2026.4.14 (323493f) — I keep secrets like a vault... unless you print them in debug logs again.
│ ◒ Probing openai-codex (openai-codex:abelvesa@gmail.com (abelvesa@gmail.com))[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" } }

left ingotBOT
#

Yep, that’s the exact cause.

refresh_token_reused means OpenAI already rotated that refresh token somewhere else, and this agent is now holding a stale copy. So this is not an auth-order mystery anymore, the token is dead.

Fix for the failing agent:

OPENCLAW_AGENT_DIR=~/.openclaw/agents/<agentId>/agent \
  openclaw models auth login --provider openai-codex

Why it usually happens:

  • another agent is using the same Codex OAuth login
  • Codex CLI / another host refreshed the same account
  • the same auth-profiles.json got copied between agents and they invalidated each other later

So if it keeps coming back after re-auth, I’d look for another place using that same Codex account/token.

left ingotBOT
#

Then I’d stop assuming it’s just “bad token” and start checking wrong store / wrong agent / stale gateway state.

If re-auth didn’t fix it, the most common failure is: you wrote fresh creds to one agentDir, but the failing session is actually reading a different one.

Next checks:

  1. In the failing chat/session, run:

    /model status
    

    That should show the active agent and the exact auth-profiles.json path it’s using.

  2. On the gateway host, run:

    openclaw agents list --bindings
    openclaw models auth order get --provider openai-codex --agent <that-agent-id>
    
#
   openclaw doctor
   openclaw gateway restart

What I’m looking for:

  • /model status shows a different agent/path than the one you re-authed
  • agents list --bindings shows the thread is routed to a different agent than expected
  • doctor warns about multiple state dirs or a stale models.providers.openai-codex override
  • restart fixes a stale in-memory auth/cache situation

So yeah, at this point I suspect path/routing mismatch more than the login flow itself.

Paste /model status plus openclaw agents list --bindings, that should narrow it down fast.

sage mica
#

how do I configure all agents to use a single login

left ingotBOT
#

Short version: there isn’t a real “all agents share one live Codex login” switch today.

Auth is per-agent. Each agent has its own:

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

What is supported:

  • Manual seeding: copy one agent’s auth-profiles.json into the other agents’ agentDirs
  • Do not share/reuse the whole agentDir

But for openai-codex OAuth, that’s a bit fragile, because refresh tokens rotate. So one agent can end up with a newer token while the others still hold an old one, which is exactly how you get refresh_token_reused.

So my recommendation is:

  1. If you want truly shared auth across many agents: use openai/* with an OPENAI_API_KEY
  2. If you want Codex OAuth specifically: use either
#
  • one agent, or
    • separate Codex logins per agent

If you still want the manual copy approach, it’s this file:

~/.openclaw/agents/main/agent/auth-profiles.json

copy to:

~/.openclaw/agents/<other-agent>/agent/auth-profiles.json

Just know that for Codex OAuth this is more “seed the other agents” than “shared live login”.