“Could not decrypt legacy OAuth sidecar” after 5.18 update

[floral vortex]

After updating to 5.18, several agents don’t respond in channels and I get this message in “openclaw doctor” for several agents: “ - Could not decrypt legacy OAuth sidecar for openai-codex:[email address] in ~/.openclaw/agents/forge/agent/auth-profiles.json; re-authenticate this profile.” Running “openclaw doctor —fix” did not fix this. Re-authenticating with “openclaw models auth login —provider openai-codex” did not fix it either.

[sturdy mirage]

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

[fringe quarry]

First thing: please paste the exact openclaw --version output, just so we know whether this is a 5.18 stable/beta mismatch.

I checked current docs/source. The important bit is that model auth is per-agent: the path in the warning is for agent forge:

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

So re-authing without an agent probably refreshed the default/main agent, not forge.

Try this for each affected agent id from the doctor warning:

openclaw models auth list --agent forge --provider openai-codex
openclaw models auth login --agent forge --provider openai-codex
openclaw models status --agent forge --probe --probe-provider openai-codex
openclaw gateway restart

[fringe quarry]

If you are remote/headless and 5.18 supports it, use device-code login:

openclaw models auth login --agent forge --provider openai-codex --device-code

Why doctor --fix did not fix it: this warning means OpenClaw cannot decrypt old OAuth material. Doctor can repair routing/config, but it cannot recover an unreadable refresh token; the affected agent profile needs a fresh OAuth login.

If the same warning remains after agent-scoped login, make a backup of that agent’s auth store before touching anything:

cp ~/.openclaw/agents/forge/agent/auth-profiles.json ~/.openclaw/agents/forge/agent/auth-profiles.json.bak

Then share the output of:

[fringe quarry]

openclaw models auth list --agent forge --provider openai-codex
openclaw models status --agent forge --probe --probe-provider openai-codex

Docs I checked: https://docs.openclaw.ai/providers/openai, https://docs.openclaw.ai/concepts/oauth, https://docs.openclaw.ai/gateway/doctor

[floral vortex]

Can I do this for multiple agents at once?

[fringe quarry]

Not as a single built-in models auth login command, as far as I can tell. --agent targets one agent at a time.

You can batch the inspection though:

for a in forge agent2 agent3; do
  echo "=== $a ==="
  openclaw models auth list --agent "$a" --provider openai-codex
  openclaw models status --agent "$a" --probe --probe-provider openai-codex
done

For the actual OAuth login, I’d do them one at a time:

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

[fringe quarry]

openclaw models auth login --agent agent2 --provider openai-codex
openclaw models auth login --agent agent3 --provider openai-codex

If all those agents should use the same account, there may be a cleaner route: fix the main/default agent auth and remove/repair only the stale per-agent auth store that is shadowing it. I would not delete those files blind, though. Back them up first and confirm with models auth list --agent <id> --provider openai-codex which profiles are actually present.

[floral vortex]

Can this be done by way of manually modifying the auth-profiles.json for the affected agents?

[fringe quarry]

Yes, but I’d frame it as “remove stale per-agent auth that is shadowing good auth,” not “hand-edit OAuth tokens.”

Don’t try to manually paste/edit the OAuth token fields. The warning says the old OAuth sidecar cannot be decrypted, and JSON editing won’t magically make that encrypted material valid again.

Safer manual route, if all affected agents should use the same OpenAI/Codex account as your main/default agent:

1. Confirm main/default has a good profile:

openclaw models auth list --provider openai-codex
openclaw models status --probe --probe-provider openai-codex

2. For each affected agent, back up its per-agent auth store and move it aside:

[fringe quarry]

for a in forge agent2 agent3; do
  dir="$HOME/.openclaw/agents/$a/agent"
  test -f "$dir/auth-profiles.json" || continue
  cp "$dir/auth-profiles.json" "$dir/auth-profiles.json.bak.$(date +%Y%m%d-%H%M%S)"
  mv "$dir/auth-profiles.json" "$dir/auth-profiles.json.disabled"
done

3. Restart and re-check one affected agent:

openclaw gateway restart
openclaw models auth list --agent forge --provider openai-codex
openclaw models status --agent forge --probe --probe-provider openai-codex
openclaw doctor

[fringe quarry]

Current behavior I checked: if a secondary agent has no auth-profiles store, OpenClaw can inherit auth profiles from the main agent. But if that agent has its own stale auth-profiles.json, that file can take precedence and keep the broken profile around.

Caveat: if those agents have different provider keys/accounts in their auth store, moving the whole file aside will affect those too. In that case, back up first, then either re-auth each agent explicitly or surgically remove only the broken openai-codex:* entries.

[floral vortex]

Yeah the command in step 2 worked. Maybe updates should include a step asking to set all agents auth profiles to the same as main?

[fringe quarry]

Nice, glad step 2 worked.

I’d frame that a little differently: updates probably shouldn’t tell everyone to force all agent auth profiles to match main, because some setups intentionally use separate auth per agent. But the updater/migration should probably detect this legacy sidecar/auth-profile mismatch and either repair it or print a very explicit “these agents need auth reassigned” warning.

If you have a minute, this is worth filing as a GitHub issue with the exact update path + the command that fixed it: https://github.com/openclaw/openclaw/issues

And if this solved the thread, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it.

[floral vortex]

It isn’t enough to say the agents need auth reassigned - that is bad UX and people do not understand; when this “could not decrypt legacy OAuth sidecar” situation arises, the interactive “openclaw update” flow and/or “openclaw doctor” flow should ask if the user would like to remove/reset all non-main agents auth-profiles.json configurations to make them align with main, as an interactive option. The user can say no, but should be explicitly and interactively prompted.

[fringe quarry]

Yep, that’s a better UX target. I agree: a passive warning is probably too weak here.

The interactive flow should be closer to:

“Some non-main agents have legacy OAuth/auth profile data that cannot be decrypted. This can prevent those agents from using the working main auth profile. Do you want to reset non-main agent auth profile config so they inherit/align with main? [yes/no]”

With a clear list of affected agent ids before it does anything, and no preserving advanced/custom per-agent auth setups.

That’s specific enough for a good issue: openclaw update and/or openclaw doctor should detect the decrypt failure state and offer an interactive repair, not just tell users to manually reassign auth.

[floral vortex]

Yes. Draft a fix PR here and I’ll then give it to one of my agents to finalize and upload via gh cli using my gh creds.

[fringe quarry]

I can’t make project code changes or draft an actual PR from here because this Discord support context is read-only for project ops.

But here’s a concrete PR brief your agent can use:

Title: fix(auth): offer interactive repair for undecryptable legacy agent OAuth sidecars

Goal: when openclaw update and/or openclaw doctor detects Could not decrypt legacy OAuth sidecar for non-main agents, don’t stop at logging. In interactive mode, show affected agent ids/paths and ask whether to reset/remove their per-agent auth-profiles.json / legacy sidecar auth state so they fall back to or align with main auth.

Expected behavior:

• Detect decrypt failures for non-main agent auth sidecars during update/doctor auth checks.
• Print a clear explanation that custom per-agent auth may be preserved by choosing no.
• Prompt: Reset auth config for affected non-main agents so they use main auth? [y/N]
• Default to no.
• On yes, move old files aside if possible instead of hard-deleting, e.g. .bak.<timestamp>, then re-run/advise re-run auth validation.
• Never touch main auth automatically.
• Non-interactive mode should emit an actionable warning plus the exact command/flag to run the repair if you add one.

[fringe quarry]

Tests:

• Fixture with undecryptable legacy sidecar on a non-main agent triggers prompt.
• Choosing no leaves files unchanged.
• Choosing yes backs up/removes only affected non-main auth config.
• Main agent auth is not modified.
• Non-interactive update/doctor does not mutate files.

That should be enough for an implementation agent to turn into a patch without guessing the UX.