Reuse Codex OAuth for OpenAI Realtime voice#100671
Conversation
openclaw-barnacle
Bot
added
docs
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 312de7de40
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| provider: "openai", | ||
| cfg: params.cfg, | ||
| profileTypes: ["oauth"], | ||
| includeExternalCliAuth: true, |
There was a problem hiding this comment.
When a user has the legacy Codex profile pinned in auth.order.openai (for example openai:codex-cli), this lookup only scopes external CLI discovery by provider. The Codex overlay is therefore created as openai:default, while resolveAuthProfileOrder treats a configured order as a hard constraint, so the overlaid profile is filtered out and Realtime still reports missing auth despite a valid Codex login. This is the same config shape the Discord bridge test now threads through; pass the ordered profile id/preferred profile into discovery or normalize the legacy Codex id before resolving OAuth.
Useful? React with 👍 / 👎.
|
Codex review: found issues before merge. Reviewed July 6, 2026, 2:58 AM ET / 06:58 UTC. Summary PR surface: Source +26, Tests +92, Docs +2. Total +120 across 7 files. Reproducibility: yes. source inspection gives a high-confidence reproduction path: configure Review metrics: 1 noteworthy metric.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Copy recommended automerge instructionNext step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Land the OAuth fallback only after the provider-auth path preserves pinned legacy Codex profile ids and the tests prove both default Codex OAuth and ordered Do we have a high-confidence way to reproduce the issue? Yes, source inspection gives a high-confidence reproduction path: configure Is this the best way to solve the issue? No, not yet: reusing Codex OAuth is a maintainable direction only if the provider-auth fallback preserves the user's configured profile id or normalizes the legacy Codex id before order filtering. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 9dfd9324f2ec. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +26, Tests +92, Docs +2. Total +120 across 7 files. View PR surface stats
Acceptance criteria:
What I checked:
Likely related people:
What the crustacean ranks mean
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
|
312de7d to
a36b455
Compare
clawsweeper
Bot
added
proof: sufficient
a36b455 to
e6d56b1
Compare
e6d56b1 to
3f4771f
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3f4771fb63
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| cfg: this.config.cfg, | ||
| }); | ||
| return this.resolveApiKeyConnectionParams(apiKey, model); | ||
| return this.resolveApiKeyConnectionParams(authToken, model); |
There was a problem hiding this comment.
When the selected credential is an openai OAuth/Codex profile, requireOpenAIRealtimePlatformAuthToken can return the raw OAuth access token, but this line still opens the native backend WebSocket as if that token were a standard Platform API key. OpenAI's Realtime WebSocket guide documents server-to-server WebSocket auth with an API key, while this repo's transcription OAuth path first mints a Realtime client secret before using OAuth (extensions/openai/realtime-transcription-provider.ts:146-158). As a result, Voice Call, Discord voice, Google Meet, and gateway-relay sessions that rely only on Codex OAuth will advertise as configured but fail the backend WebSocket auth; mint and use a Realtime client secret for the OAuth branch instead of passing the OAuth token directly here.
Useful? React with 👍 / 👎.
* origin/main: fix(ci): restore gateway architecture and lint gates (openclaw#100703) fix(openai): reuse Codex auth for realtime voice (openclaw#100671) perf(test): avoid provider runtime in auth doctor unit test docs(android): credit landed app improvements (openclaw#100702)
Co-authored-by: Peter Steinberger <[email protected]>
Co-authored-by: Peter Steinberger <[email protected]>
2 participants
Summary
openaiOAuth profile or external Codex loginOPENAI_API_KEYahead of OAuth, including fail-closed behavior for unresolved keysVerification
session.createdandsession.updatedover the Realtime WebSocket with Codex OAuthpnpm exec vitest run extensions/openai/realtime-voice-provider.test.ts --reporter=dot(63 passed)node scripts/run-vitest.mjs run --config test/vitest/vitest.e2e.config.ts extensions/discord/src/voice/manager.e2e.test.ts -t "uses agent-proxy realtime voice by default" --reporter=dot(1 passed)pnpm exec tsc --noEmit --project extensions/openai/tsconfig.jsonpnpm exec oxfmt --check ...on all changed files