Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix /status shows codex/* auth as unknown even when Codex CLI auth is available [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70688•Fetched 2026-04-24 05:54:40
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
jb510jb510
Participants
jb510jb510
Timeline (top)
closed ×1cross-referenced ×1referenced ×1

When a session is using the native codex/* provider and valid Codex CLI auth is present in CODEX_HOME / ~/.codex/auth.json, /status still reports:

  • 🔑 unknown

This is misleading because the runtime can still be correctly authenticated through the Codex CLI auth path.

Root Cause

resolveModelAuthLabel() and resolveModelAuthMode() currently derive auth state from:

  • OpenClaw auth-profile stores
  • env-based API keys / oauth env vars
  • models.json custom provider keys

But for provider codex, they do not consult readCodexCliCredentialsCached() / the Codex CLI auth source.

As a result:

  • /status shows 🔑 unknown for codex/*
  • other status/auth-mode displays can also misclassify codex as unauthenticated

Fix Action

Fixed

PR fix notes

PR #70689: status: detect Codex CLI auth for codex provider

Description (problem / solution / changelog)

Fixes #70688.

Summary

Teach status/auth-mode helpers to recognize Codex CLI credentials for normalized provider codex.

Before this change, /status could show:

🧠 Model: codex/gpt-5.4 · 🔑 unknown

…even when valid Codex CLI auth existed in CODEX_HOME / ~/.codex/auth.json.

After this change, the same state is reported as Codex OAuth instead of unknown.

Changes

  • update resolveModelAuthLabel() to return oauth (codex-cli) for provider codex when readCodexCliCredentialsCached() succeeds
  • update resolveModelAuthMode() to return oauth for provider codex under the same condition
  • add focused tests for both helpers
  • merge current main and keep the Vertex ADC marker test aligned with existing non-credential semantics

Validation

  • node scripts/run-vitest.mjs run --config test/vitest/vitest.agents.config.ts src/agents/model-auth-label.test.ts src/agents/model-auth.test.ts
  • OPENCLAW_VITEST_MAX_WORKERS=2 node scripts/run-vitest.mjs run --config test/vitest/vitest.full-core-support-boundary.config.ts

Changed files

  • src/agents/model-auth-label.test.ts (modified, +29/-0)
  • src/agents/model-auth-label.ts (modified, +5/-0)
  • src/agents/model-auth.test.ts (modified, +18/-0)
  • src/agents/model-auth.ts (modified, +8/-0)

Code Example

🧠 Model: codex/gpt-5.4 · 🔑 unknown

---

🧠 Model: codex/gpt-5.4 · 🔑 oauth (codex-cli)

---

🧠 Model: codex/gpt-5.4 · 🔑 unknown
RAW_BUFFERClick to expand / collapse

Summary

When a session is using the native codex/* provider and valid Codex CLI auth is present in CODEX_HOME / ~/.codex/auth.json, /status still reports:

  • 🔑 unknown

This is misleading because the runtime can still be correctly authenticated through the Codex CLI auth path.

Why this looks like a bug

On a live OpenClaw host running codex/gpt-5.4, I observed:

🧠 Model: codex/gpt-5.4 · 🔑 unknown

At the same time:

  • ~/.codex/auth.json contained valid ChatGPT/Codex OAuth tokens
  • the embedded Codex auth copy used by OpenClaw also existed and matched
  • the session's selected model/provider was codex/gpt-5.4

The status output implied "no auth", but the actual problem was that the status/auth-label path does not inspect Codex CLI credentials for provider codex.

Root cause

resolveModelAuthLabel() and resolveModelAuthMode() currently derive auth state from:

  • OpenClaw auth-profile stores
  • env-based API keys / oauth env vars
  • models.json custom provider keys

But for provider codex, they do not consult readCodexCliCredentialsCached() / the Codex CLI auth source.

As a result:

  • /status shows 🔑 unknown for codex/*
  • other status/auth-mode displays can also misclassify codex as unauthenticated

Expected behavior

When provider is codex and valid Codex CLI credentials are available, status should report OAuth auth, e.g.:

🧠 Model: codex/gpt-5.4 · 🔑 oauth (codex-cli)

Actual behavior

🧠 Model: codex/gpt-5.4 · 🔑 unknown

Proposed fix

Teach both of these helpers to recognize Codex CLI auth for normalized provider codex:

  • src/agents/model-auth-label.ts
  • src/agents/model-auth.ts

Specifically:

  • in resolveModelAuthLabel(), return oauth (codex-cli) when readCodexCliCredentialsCached() returns a valid credential for provider codex
  • in resolveModelAuthMode(), return oauth for provider codex when the same Codex CLI credential is available

Notes

This issue is about status/auth display correctness, not proving whether a given run actually fell back to some other provider. The incorrect unknown label makes that debugging much harder.

extent analysis

TL;DR

Update resolveModelAuthLabel() and resolveModelAuthMode() to recognize Codex CLI auth for the codex provider.

Guidance

  • Modify src/agents/model-auth-label.ts to return oauth (codex-cli) when readCodexCliCredentialsCached() returns a valid credential for provider codex.
  • Modify src/agents/model-auth.ts to return oauth for provider codex when the same Codex CLI credential is available.
  • Verify the fix by checking the /status output for codex/* providers with valid Codex CLI credentials.
  • Ensure that the changes do not introduce any unintended behavior for other providers or authentication methods.

Example

// src/agents/model-auth-label.ts
function resolveModelAuthLabel(provider: string) {
  if (provider === 'codex' && readCodexCliCredentialsCached()) {
    return 'oauth (codex-cli)';
  }
  // existing logic
}

Notes

The proposed fix only addresses the display correctness of the authentication status and does not affect the actual authentication mechanism.

Recommendation

Apply the proposed workaround by updating the resolveModelAuthLabel() and resolveModelAuthMode() functions to recognize Codex CLI auth for the codex provider, as this will correctly display the authentication status for codex/* providers.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

When provider is codex and valid Codex CLI credentials are available, status should report OAuth auth, e.g.:

🧠 Model: codex/gpt-5.4 · 🔑 oauth (codex-cli)
#api#batch processing#GPU compatibility#latency issue#model loading

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING