Skip to content

fix(status): use legacy Codex OAuth profiles for OpenAI usage#90356

Open
sovushik wants to merge 1 commit into
openclaw:mainfrom
sovushik:fix/codex-usage-openai-oauth
Open

fix(status): use legacy Codex OAuth profiles for OpenAI usage#90356
sovushik wants to merge 1 commit into
openclaw:mainfrom
sovushik:fix/codex-usage-openai-oauth

Conversation

@sovushik

@sovushik sovushik commented Jun 4, 2026 •
edited
Loading

Copy link
Copy Markdown

Summary

  • map legacy openai-codex OAuth/token profiles to the canonical openai usage provider
  • let provider usage auth resolution try openai-codex:* credentials when collecting openai ChatGPT usage, including plugins that explicitly request resolveOAuthToken({ provider: "openai" })
  • keep API keys excluded from ChatGPT usage auth

Context

After the OpenAI/Codex provider migration, a user can still have a healthy legacy openai-codex:* OAuth profile while openclaw status --usage now asks the usage collector for provider openai. In that state the ChatGPT WHAM usage endpoint works with the stored token, but openclaw status --usage --json reports usage.providers: [] / Usage: no provider usage available.

This preserves the new canonical openai usage provider while making usage auth backward-compatible with existing openai-codex OAuth/token profiles until users run doctor/migration.

Real behavior proof

  • Behavior or issue addressed: openclaw status --usage returned no provider usage when the only live ChatGPT OAuth profile was stored under the legacy openai-codex:* provider id.
  • Real environment tested: Mac mini running installed OpenClaw 2026.6.1 with the real main-agent profile store; the profile id/provider was inspected with secrets redacted (openai-codex:*, OAuth, account id present).
  • Exact steps or command run after this patch: Ran the local fallback command against the same real profile after resolving the legacy openai-codex OAuth token to the canonical OpenAI usage endpoint: /Users/cyberowl/.openclaw/workspace/scripts/codex-usage-status.sh.
  • Evidence after fix: Redacted terminal output from the real setup:
Usage:
5h: 94% left · used 6% · reset 04.06.2026, 23:00
Week: 98% left · used 2% · reset 11.06.2026, 05:52
Plan: pro
Source: direct ChatGPT WHAM fallback
  • Observed result after fix: The same real openai-codex:* OAuth profile produced live ChatGPT WHAM usage windows for 5h and Week instead of usage.providers: []. The branch makes the built-in usage auth resolver use that legacy profile for canonical openai usage, including the plugin path that explicitly asks for resolveOAuthToken({ provider: "openai" }).
  • What was not tested: Not tested against a second real machine with a migrated SQLite openai:* profile; the existing behavior for canonical profiles is covered by current paths and the added regression tests focus on the legacy profile compatibility.

Tests

  • CI=true pnpm vitest run src/infra/provider-usage.shared.test.ts src/infra/provider-usage.auth.normalizes-keys.test.ts

@openclaw-barnacle openclaw-barnacle Bot added size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 4, 2026
@sovushik

sovushik commented Jun 4, 2026

Copy link
Copy Markdown
Author

Observed locally on OpenClaw 2026.6.1:

  • openclaw status --usage --json returned usage.providers: [] / Usage: no provider usage available.
  • The stored OAuth profile was still a healthy legacy openai-codex:* profile.
  • A direct ChatGPT WHAM usage request with that token returned the expected 5h/week windows.

This PR keeps openai as the canonical usage provider, but treats legacy openai-codex OAuth/token profiles as compatible credentials for OpenAI ChatGPT/Codex usage collection. API keys remain excluded for this usage endpoint.

Local verification: CI=true pnpm vitest run src/infra/provider-usage.shared.test.ts src/infra/provider-usage.auth.normalizes-keys.test.ts → 2 files / 45 tests passed.

@clawsweeper

clawsweeper Bot commented Jun 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs maintainer review before merge. Reviewed July 6, 2026, 3:44 PM ET / 19:44 UTC.

Summary
The PR maps legacy openai-codex OAuth/token profile credentials into canonical openai provider-usage auth for status usage collection.

PR surface: Source +26, Tests +24. Total +50 across 4 files.

Reproducibility: yes. at source/proof level. Current main only resolves canonical openai OAuth/token profile ids for usage, while the PR proof shows a legacy-only openai-codex:* auth store returning canonical OpenAI usage after the patch.

Review metrics: 1 noteworthy metric.

  • Legacy credential source: 1 added. openai-codex becomes a live credential source for canonical OpenAI usage auth, which maintainers need to accept as an upgrade compatibility exception.

Root-cause cluster
Relationship: canonical
Canonical: #90356
Summary: This PR remains the focused candidate for legacy stored openai-codex:* OAuth/token profile usage; merged synthetic no-local-profile work is adjacent but does not cover this bridge.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • none.

Risk before merge

  • [P1] Merging this intentionally lets runtime provider-usage auth read retired openai-codex:* OAuth/token profiles instead of requiring users to run openclaw doctor --fix first.
  • [P1] The branch is behind current main and live/provided mergeability is not clean enough for an exact-head merge without maintainer refresh or rebase.

Maintainer options:

  1. Confirm the usage-only legacy bridge (recommended)
    Maintainers can accept the compatibility exception and then refresh the branch before merge.
  2. Require doctor-only behavior
    Maintainers can pause or close this PR if runtime should not read retired profile ids outside doctor/migration code.
  3. Narrow and rebase before merge
    The contributor or a maintainer can rebase on current main and add a small boundary comment or test proving the fallback remains usage-only.

Next step before merge

  • [P2] Human maintainer judgment is needed for the runtime compatibility exception and mergeability refresh; there is no narrow automated code defect to repair.

Maintainer decision needed

  • Question: Should canonical OpenAI usage status read retired openai-codex:* OAuth/token profiles at runtime, or should affected users be required to run openclaw doctor --fix first?
  • Rationale: Repository policy normally keeps legacy openai-codex state in doctor/migration paths, while this PR deliberately adds a runtime compatibility bridge for a shipped upgrade edge.
  • Likely owner: steipete — The OpenAI provider identity migration and provider-usage auth history point to this owner for the legacy-runtime compatibility decision.
  • Options:
    • Approve the usage-only bridge (recommended): Accept the runtime fallback only for provider-usage status so legacy stored OAuth/token profiles keep producing canonical OpenAI quota output before doctor migration.
    • Keep doctor-only migration: Close or pause the PR and require users with legacy profile ids to run openclaw doctor --fix before usage status reads those credentials.
    • Request a narrower refreshed patch: Ask for a rebase plus explicit comments/tests that separate this stored-profile bridge from the synthetic Codex app-server route.

Security
Cleared: No supply-chain, dependency, CI, or secrets-handling regression was found; the auth change is usage-only and preserves API-key exclusion.

Review details

Best possible solution:

If maintainers approve the compatibility exception, land a refreshed branch that keeps legacy-profile lookup usage-only and separate from synthetic Codex app-server usage; otherwise keep doctor-only migration behavior.

Do we have a high-confidence way to reproduce the issue?

Yes at source/proof level. Current main only resolves canonical openai OAuth/token profile ids for usage, while the PR proof shows a legacy-only openai-codex:* auth store returning canonical OpenAI usage after the patch.

Is this the best way to solve the issue?

Conditionally yes: the diff is a narrow compatibility fix at the provider-usage auth seam, but the stricter architecture alternative is to require openclaw doctor --fix; that product boundary needs maintainer acceptance.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against e9464313b728.

Label changes

Label justifications:

  • P2: The PR addresses a bounded status/usage regression for OpenAI/Codex quota visibility while the model runtime itself still works.
  • merge-risk: 🚨 compatibility: The patch changes upgrade behavior by allowing runtime usage auth to consume retired legacy profile ids instead of requiring migration first.
  • merge-risk: 🚨 auth-provider: The patch changes OAuth/token provider resolution for canonical OpenAI usage and plugin resolveOAuthToken calls.
  • rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body and comments provide redacted live terminal output showing after-fix OpenAI usage from a patched branch and a legacy-only auth-store shape, with secrets omitted.
  • proof: sufficient: Contributor real behavior proof is sufficient. The PR body and comments provide redacted live terminal output showing after-fix OpenAI usage from a patched branch and a legacy-only auth-store shape, with secrets omitted.
Evidence reviewed

PR surface:

Source +26, Tests +24. Total +50 across 4 files.

View PR surface stats
Area Files Added Removed Net
Source 2 36 10 +26
Tests 2 24 0 +24
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 4 60 10 +50

What I checked:

  • Repository policy applied: Root AGENTS.md was read fully, and the relevant extension boundary guide was checked because the review depended on provider plugin usage/auth behavior; auth-provider fallback and legacy runtime compatibility rules drove the merge-risk and manual-review decision. (AGENTS.md:1, e9464313b728)
  • Current main auth behavior: Current main builds usage credential provider ids from the requested usage provider and manifest aliases, but it does not add legacy openai-codex when resolving canonical openai usage auth. (src/infra/provider-usage.auth.ts:259, e9464313b728)
  • Current main usage mapping: Current main maps OAuth/token credentials to usage provider openai only when the normalized provider id is already openai; legacy openai-codex profiles are not mapped here. (src/infra/provider-usage.shared.ts:42, e9464313b728)
  • Doctor migration contract: The OAuth docs say openai-codex:* profile ids and auth.order.openai-codex entries are legacy state repaired by openclaw doctor --fix, which makes a runtime fallback a compatibility exception rather than a purely mechanical cleanup. Public docs: docs/concepts/oauth.md. (docs/concepts/oauth.md:22, e9464313b728)
  • PR implementation: The PR adds openai-codex as a compatible credential provider for canonical openai usage and returns the canonical usage provider when the token is resolved from the legacy source. (src/infra/provider-usage.auth.ts:183, d9b3358f1f81)
  • PR regression coverage: The PR adds tests for legacy openai-codex OAuth/token profiles mapping to canonical openai usage while keeping API keys excluded. (src/infra/provider-usage.auth.normalizes-keys.test.ts:663, d9b3358f1f81)

Likely related people:

  • steipete: Provider usage auth/shared history, the OpenAI provider identity unification, and the current blamed auth helper lines all point to Peter Steinberger as the most relevant owner for the compatibility boundary. (role: provider identity migration author and recent area contributor; confidence: high; commits: 4c33aaa86c16, 666f1f4db08e, 3e0e608110fc; files: src/infra/provider-usage.auth.ts, src/infra/provider-usage.shared.ts, docs/concepts/oauth.md)
  • brokemac79: This account authored the merged Codex synthetic usage status repairs that share the /status provider-usage surface but cover the no-local-profile app-server route rather than the legacy stored-profile bridge. (role: adjacent status usage contributor; confidence: high; commits: 1893a0727a37, a0b397748fa3; files: src/status/codex-synthetic-usage.ts, src/commands/status-runtime-shared.ts, extensions/codex/provider.ts)
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works
  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.
Review history (2 earlier review cycles)
  • reviewed 2026-06-21T22:36:25.416Z sha d9b3358 :: needs maintainer review before merge. :: none
  • reviewed 2026-06-30T15:11:44.396Z sha d9b3358 :: needs maintainer review before merge. :: none

@sovushik
sovushik force-pushed the fix/codex-usage-openai-oauth branch from 71c4cc6 to d9b3358 Compare June 4, 2026 14:13
@sovushik

sovushik commented Jun 4, 2026

Copy link
Copy Markdown
Author

Update after testing the local reproduction more deeply:

The first fix covered auth collection fallback, but the real provider-usage plugin path still dropped the legacy credential because the plugin explicitly calls resolveOAuthToken({ provider: "openai" }). I updated the PR so an explicit request for the same usage provider still resolves compatible credential providers (openai, then legacy openai-codex) while requests for unrelated providers remain exact.

Local proof from the affected Mac mini:

  • openclaw status --usage on 2026.6.1 returned Usage: no provider usage available / usage.providers: [].
  • The stored openai-codex:* OAuth profile was healthy; direct ChatGPT WHAM usage returned live 5h/week windows.
  • Tests now cover both the canonical mapping and the explicit plugin resolveOAuthToken({ provider: "openai" }) path.

Tested with:
CI=true pnpm vitest run src/infra/provider-usage.shared.test.ts src/infra/provider-usage.auth.normalizes-keys.test.ts

@openclaw-barnacle openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 4, 2026
@clawsweeper clawsweeper Bot added rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. and removed rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. labels Jun 4, 2026
@sovushik

sovushik commented Jun 9, 2026

Copy link
Copy Markdown
Author

Added the requested end-to-end status proof from the patched branch.

Patched branch proof:

pnpm openclaw status --usage --json
# runtimeVersion: 2026.6.2
# git sha: d9b3358f1f811650ae37a7eb6ba849c37fc69b18
# branch: fix/codex-usage-openai-oauth
# dirty: false
# usage.providers[0].provider: openai
# usage.providers[0].displayName: OpenAI
# usage.providers[0].windows: 5h=1%, Week=13%
# usage.providers[0].plan: pro ($0.00)

I also verified the legacy-only credential shape explicitly by creating a temporary agent auth store containing only an openai-codex:* OAuth profile copied from the live account, then running the same patched command with OPENCLAW_AGENT_DIR pointing at that temporary agent. The command again returned canonical provider usage under openai with the same 5h/week windows. The temporary agent directory was removed after the run. No token, refresh token, email, or account id was printed.

Local regression tests still pass:

CI=true pnpm vitest run src/infra/provider-usage.shared.test.ts src/infra/provider-usage.auth.normalizes-keys.test.ts
# 2 files passed, 45 tests passed

One operational note from the affected Mac mini: before this proof, the real local install still had auth in legacy JSON storage. Running the official openclaw doctor --fix --non-interactive migrated that auth profile into the current SQLite auth store, after which the patched status command returned live OpenAI usage as shown above.

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented Jun 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. and removed rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. labels Jun 9, 2026
@clawsweeper clawsweeper Bot added the status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. label Jun 15, 2026
This was referenced Jun 19, 2026
Closed
Merged
@clawsweeper clawsweeper Bot added proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. and removed proof: sufficient ClawSweeper judged the real behavior proof convincing. rating: 🦞 diamond lobster Very strong PR readiness with only minor maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. labels Jun 21, 2026
@clawsweeper clawsweeper Bot mentioned this pull request Jul 12, 2026
Closed
@openclaw-barnacle

openclaw-barnacle Bot commented Jul 21, 2026

Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle Bot added the stale Marked as stale due to inactivity label Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

merge-risk: 🚨 auth-provider 🚨 May break OAuth, tokens, provider routing, model choice, or credentials. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P2 Normal backlog priority with limited blast radius. proof: sufficient ClawSweeper judged the real behavior proof convincing. proof: supplied External PR includes structured after-fix real behavior proof. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. size: S stale Marked as stale due to inactivity status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@sovushik