Bug type

Authentication / profile selection regression

Summary

This appears to be the same failure mode as #57286, but that issue is locked so I cannot add the requested current-build reproduction there.

On OpenClaw 2026.5.18, running openclaw models auth login --provider openai-codex successfully created a fresh named OAuth profile, and models auth order set was used to put that fresh profile first. However, auth-state.json still moved/kept lastGood.openai-codex on the older openai-codex:default profile. Since the installed selection path prefers lastGood before the first ordered profile, runtime/status can continue selecting stale default credentials unless the operator manually edits/copies auth profiles.

Environment

• OpenClaw: 2026.5.18 (50a2481)
• Codex CLI: codex-cli 0.130.0
• OS: macOS / Apple Silicon
• Auth flow: openclaw models auth login --provider openai-codex
• OAuth completion: mobile browser login, then manual localhost callback URL/code entry into the CLI prompt

Steps to reproduce

1. Start with an existing openai-codex:default OAuth profile near expiry.

2. Run:

   openclaw models auth login --provider openai-codex

3. Complete OAuth. In this case the login wrote a fresh named profile:

   openai-codex:<email>
   

4. Set provider auth order to prefer the fresh named profile:

   openclaw models auth order set --provider openai-codex --agent main openai-codex:<email> openai-codex:default

5. Check ~/.openclaw/agents/main/agent/auth-state.json.

Expected behavior

After successful reauth and explicit auth-order selection, OpenClaw should either:

• update lastGood.openai-codex to the fresh profile,
• clear stale lastGood for that provider,
• or make explicit auth order override lastGood when choosing an active profile.

The fresh profile should be the effective profile without manual auth-store edits.

Actual behavior

After successful login, the agent had two profiles:

- openai-codex:default (same ChatGPT account) [openai-codex/oauth; expires 2026-05-22T15:07:22.131Z]
- openai-codex:<email> (same ChatGPT account) [openai-codex/oauth; expires 2026-05-30T01:09:04.729Z]

The order was set correctly:

{
  "order": {
    "openai-codex": [
      "openai-codex:<email>",
      "openai-codex:default"
    ]
  }
}

But lastGood still selected the old default profile:

{
  "lastGood": {
    "openai-codex": "openai-codex:default"
  }
}

The installed 2026.5.18 bundle appears to prefer lastGood ahead of the first ordered profile when the lastGood profile is present in the order and not currently marked unusable/cooldowned:

const lastGood = [
  params.store.lastGood?.[OPENAI_PROVIDER_ID],
  params.store.lastGood?.[OPENAI_CODEX_PROVIDER_ID],
].find((profileId) =>
  !!profileId &&
  params.order.includes(profileId) &&
  isActiveProfileCandidate(params, profileId)
);
if (lastGood) return lastGood;

Workaround

The robust local workaround was to copy the fresh named OAuth credential material into openai-codex:default as well. After that, both profile ids reported the new expiry:

openai-codex:default        expires 2026-05-30T01:09:04.729Z
openai-codex:<email>        expires 2026-05-30T01:09:04.729Z

Then this verification passed:

openclaw infer model run --model openai/gpt-5.5 --prompt 'Reply with exactly: CODEX_STATUS_OK' --json
# returned CODEX_STATUS_OK

Why this is worth tracking

This is not only a UI/status issue. The operator-visible recovery path after OAuth renewal still required manual auth-store surgery, even after:

• successful models auth login --provider openai-codex,
• explicit models auth order set,
• and a passing model-run after manually aligning the stale default profile.

The closest existing issue is #57286, but it is locked and cannot receive the requested current-build reproduction comment.

Redaction

No tokens, auth codes, account ids, hostnames, chat ids, or personal identifiers are included here. The email-bearing profile id is redacted as openai-codex:<email>.