Summary

OpenClaw's OpenAI Codex OAuth flow appears to rely on upstream @mariozechner/pi-ai/oauth workspace/account selection without validating that the selected ChatGPT workspace is still active.

If a ChatGPT account has multiple workspaces and one of them is deactivated, OAuth login may intermittently succeed but later fail with a workspace deactivated error, depending on which workspace/account context gets selected.

Environment

• OpenClaw version: 2026.3.28-beta.1
• Repo inspected: main branch of openclaw/openclaw
• Provider: openai-codex via ChatGPT OAuth

Reproduction

1. Use a ChatGPT/OpenAI account that belongs to two workspaces:
   • Workspace A: active / normal
   • Workspace B: deactivated
2. Run OpenClaw setup/login with openai-codex OAuth.
3. Complete OAuth successfully.
4. Use the provider in OpenClaw.
5. Intermittently, requests fail with an error indicating the selected workspace is deactivated.

Expected behavior

OpenClaw should not bind to or continue using a deactivated ChatGPT workspace when an active workspace is available.

Ideally it should:

• prefer an active workspace/account automatically,
• or probe and persist a usable accountId after OAuth,
• or detect workspace deactivated and retry/fallback to another active workspace,
• or at minimum surface a clearer remediation path.

Actual behavior

The OAuth flow can complete successfully, but later runtime behavior fails because the selected workspace/account context is deactivated.

Code analysis

From the current main branch, OpenClaw seems to delegate the critical workspace/account selection behavior to upstream OAuth helpers and does not add an active-workspace validation layer.

OAuth login path

src/plugins/provider-openai-codex-oauth.ts

This path calls loginOpenAICodex(...) from @mariozechner/pi-ai/oauth and returns the credentials, but I do not see any OpenClaw-side logic here that enumerates workspaces or filters out deactivated ones after login.

Provider auth result construction

extensions/openai/openai-codex-provider.ts

runOpenAICodexOAuth() builds the stored auth result from returned credentials, but does not appear to perform a post-login workspace/account sanity check before persisting them.

Usage path does support accountId, but only passively

src/infra/provider-usage.fetch.codex.ts

This code sends ChatGPT-Account-Id when accountId exists, but that only helps if the stored credential already contains a correct, active account/workspace selection.

Refresh fallback exists, but only for one narrow failure mode

extensions/openai/openai-codex-provider.ts

There is already a refresh fallback for:

• Failed to extract accountId from token

However, I do not see analogous handling for:

• workspace deactivated
• or cases where accountId extraction succeeds but resolves to a deactivated workspace

Suspected root cause

OpenClaw currently appears to trust upstream OAuth/account resolution too much for multi-workspace ChatGPT accounts.

If upstream selection is unstable / cached / defaulted to the wrong workspace, OpenClaw has no additional guardrail to:

• filter deactivated workspaces,
• pin a known-good active workspace,
• or retry on deactivated-workspace failures.

Suggested fixes

Any of these would likely improve the situation:

1. Post-OAuth workspace validation in OpenClaw

   • After OAuth succeeds, query ChatGPT backend/account metadata
   • Detect active vs deactivated workspaces
   • Persist a usable active accountId

2. Runtime fallback on workspace deactivated

   • If a request fails with workspace deactivated, do not fail immediately
   • Re-discover available workspaces/accounts
   • Retry once with a different active workspace/account
   • Persist the recovered accountId if successful

3. Upstream fix in @mariozechner/pi-ai/oauth

   • If that library is responsible for selecting workspace/account context, it should prefer active workspaces and avoid deactivated ones by default

4. Broaden current refresh fallback logic

   • Extend current narrow extract accountId fallback handling to also consider deactivated-workspace cases

Why this matters

This is especially painful because OAuth can appear to succeed, so users only discover the problem later during actual provider use. For accounts with multiple workspaces, this makes the OpenAI OAuth path feel flaky and nondeterministic.

If helpful, I can also prepare a PR sketch for either:

• OpenClaw-side post-login validation / fallback, or
• an upstream fix if the maintainers confirm the issue belongs in @mariozechner/pi-ai/oauth.