openclaw - 💡(How to fix) Fix `codex/gpt-5.5` fails after successful `codex login` because Codex synthetic auth returns `codex-app-server` instead of a real token [1 comments, 2 participants]

Title: codex/gpt-5.5 fails after successful codex login because Codex synthetic auth returns codex-app-server instead of a real token

Summary

When OpenClaw is configured to use the modern Codex provider path, for example codex/gpt-5.5, requests can still fail even though Codex CLI login succeeded.

In my case, the main model consistently failed with:

Failed to extract accountId from token

and then fell back to another provider.

The issue appears to come from the Codex extension's synthetic auth implementation: it returns the placeholder string codex-app-server as the provider token instead of resolving the real authenticated Codex token.

Environment

• OpenClaw: 2026.4.23
• Codex CLI: reproduced before and after upgrading to 0.125.0
• Main model: codex/gpt-5.5
• Fallback model during testing: kimi-code-openai/kimi-for-coding
• Host: Linux VPS

Reproduction

1. Configure OpenClaw to use a Codex model as the primary model, for example:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "codex/gpt-5.5"
      }
    }
  }
}

1. Authenticate Codex CLI successfully:

codex login

1. Confirm Codex CLI is logged in:

codex login status

1. Send a normal OpenClaw agent request.

Actual result

The Codex main model fails and OpenClaw falls back. Logs look like:

[agent/embedded] embedded run agent end: ... provider=codex error=Failed to extract accountId from token
[agent/embedded] embedded run failover decision: ... from=codex/gpt-5.5 ... rawError=Failed to extract accountId from token
[model-fallback/decision] ... candidate_failed requested=codex/gpt-5.5 candidate=codex/gpt-5.5 reason=auth ...

Expected result

If Codex CLI is already authenticated, codex/gpt-5.5 should use that authenticated state and complete normally without falling back.

Root cause

The Codex extension currently synthesizes auth in:

• extensions/codex/provider.ts
• extensions/codex/provider-discovery.ts

Both paths return:

{
  apiKey: "codex-app-server",
  source: "codex-app-server",
  mode: "token"
}

That value is a marker, not a real access token. Downstream code later treats it like a real token and eventually fails when trying to extract chatgpt_account_id / accountId.

Verified local workaround

As a local hotfix, I changed the Codex synthetic auth path to:

1. Read ~/.codex/auth.json
2. Use tokens.access_token when present
3. Fall back to codex-app-server only if no real token is available

After that change, the same request succeeded with:

winnerProvider = codex
winnerModel = gpt-5.5
fallbackUsed = false

Why this looks like an upstream bug

• It reproduces even after successful codex login
• It still reproduces after manually syncing OpenClaw auth profiles
• Replacing only the synthetic auth token source fixes the issue

That strongly suggests the problem is not user OAuth state, but how the Codex plugin resolves runtime auth.

Suggested fix

The Codex provider should resolve a real runtime token from Codex CLI state, or through a shared runtime auth helper, instead of always returning codex-app-server.

At minimum, resolveSyntheticAuth() should not hand back a placeholder token for an auth-required openai-codex-responses path when a real authenticated Codex session exists.

Additional note

Even if the final upstream fix does not read ~/.codex/auth.json directly, the current behavior still appears wrong: a placeholder marker is being returned in a path that later expects a real token with account claims.