Summary
On OpenClaw 2026.5.22, a SecretRef/static-secret migration path silently removed OAuth profiles from auth-profiles.json.
This is related to existing OAuth/runtime snapshot issues, but the observed failure mode here is different: the OAuth profiles were not merely unavailable in an in-memory runtime snapshot; the profile entries disappeared from auth-profiles.json and had to be recreated by re-running OAuth login.
Environment
- OpenClaw: 2026.5.22 (stable)
- OS: macOS 26.5 arm64
- Install/update path: npm/pnpm global OpenClaw install, gateway running via LaunchAgent
- Agent runtime: OpenAI Codex OAuth
- Affected profiles observed:
- openai-codex:
- anthropic:claude-cli
Observed behavior
After migrating static tokens to local-file SecretRefs, static-token auth was correctly externalized and openclaw secrets audit reported clean static SecretRefs.
Separately, OAuth profiles were silently dropped from auth-profiles.json. The affected setup lost at least:
- an OpenAI Codex OAuth profile
- an Anthropic Claude CLI OAuth profile
There was no clear warning and no config-audit trail for the auth-profiles.json write. The gateway itself stayed up and local CLI commands still worked, but agent runs failed once they needed the missing OAuth profile.
The user-visible failure in a cron run was:
FailoverError: No API key found for provider "openai-codex".
Auth store: /Users/.../.openclaw/agents/main/auth-profiles.json (agentDir: /Users/.../.openclaw/agents/main).
Configure auth for this agent (openclaw agents add <id>) or copy only portable static auth profiles from the main agentDir.
Re-authenticating restored the profile:
openclaw models auth login --provider openai-codex
After reauth:
openai-codex:<redacted account> [openai-codex/oauth]
Expected behavior
SecretRef/static-token migration should preserve OAuth profiles, especially profiles represented by oauthRef/credential-sidecar entries.
If a migration intentionally cannot handle OAuth profiles, it should:
- leave them untouched, or
- fail loudly before modifying auth-profiles.json, or
- write a backup and print an explicit warning naming the skipped/dropped profile ids.
Suspected root cause
The doctor/auth OAuth-sidecar migration path appears to handle static-token profiles but not OAuth profiles whose auth data is represented by oauthRef / credential sidecar references.
For type=oauth profiles with oauthRef.id pointing into a credential sidecar, the migration appears to remove the profile entry instead of preserving it or warning.
Also, config-audit.jsonl tracks openclaw.json writes, but not auth-profiles.json writes, so there is no obvious audit trail for this destructive auth-profile change.
Impact
This breaks Codex/Claude OAuth-based agent runtimes after an otherwise successful static SecretRef migration.
The failure is easy to recover from once recognized, but it is silent and confusing:
- gateway health can still look OK
- static SecretRef audit can be clean
- Telegram/cron/agent runs can fail later with a misleading "No API key found" error
- the fix requires a real terminal OAuth login
Workaround
Run this after SecretRef migration / doctor --fix / configure / plugin work:
openclaw models auth list
If the OAuth profile is missing:
openclaw models auth login --provider openai-codex
Related issues
This may be related to OAuth auth-profile snapshot issues such as #85521, but #85521 describes a runtime snapshot clobber where the on-disk auth profile survives. This report is specifically about the profile being removed from auth-profiles.json during migration/config write behavior.
Summary
On OpenClaw 2026.5.22, a SecretRef/static-secret migration path silently removed OAuth profiles from auth-profiles.json.
This is related to existing OAuth/runtime snapshot issues, but the observed failure mode here is different: the OAuth profiles were not merely unavailable in an in-memory runtime snapshot; the profile entries disappeared from auth-profiles.json and had to be recreated by re-running OAuth login.
Environment
Observed behavior
After migrating static tokens to local-file SecretRefs, static-token auth was correctly externalized and openclaw secrets audit reported clean static SecretRefs.
Separately, OAuth profiles were silently dropped from auth-profiles.json. The affected setup lost at least:
There was no clear warning and no config-audit trail for the auth-profiles.json write. The gateway itself stayed up and local CLI commands still worked, but agent runs failed once they needed the missing OAuth profile.
The user-visible failure in a cron run was:
Re-authenticating restored the profile:
After reauth:
Expected behavior
SecretRef/static-token migration should preserve OAuth profiles, especially profiles represented by oauthRef/credential-sidecar entries.
If a migration intentionally cannot handle OAuth profiles, it should:
Suspected root cause
The doctor/auth OAuth-sidecar migration path appears to handle static-token profiles but not OAuth profiles whose auth data is represented by oauthRef / credential sidecar references.
For type=oauth profiles with oauthRef.id pointing into a credential sidecar, the migration appears to remove the profile entry instead of preserving it or warning.
Also, config-audit.jsonl tracks openclaw.json writes, but not auth-profiles.json writes, so there is no obvious audit trail for this destructive auth-profile change.
Impact
This breaks Codex/Claude OAuth-based agent runtimes after an otherwise successful static SecretRef migration.
The failure is easy to recover from once recognized, but it is silent and confusing:
Workaround
Run this after SecretRef migration / doctor --fix / configure / plugin work:
If the OAuth profile is missing:
Related issues
This may be related to OAuth auth-profile snapshot issues such as #85521, but #85521 describes a runtime snapshot clobber where the on-disk auth profile survives. This report is specifically about the profile being removed from auth-profiles.json during migration/config write behavior.