fix(auth): support standard OpenAI Authorization and x-api-key headers in remote mode - #496
Conversation
.codexclaw/ is listed in .gitignore (line 11) but these two files were committed before the ignore rule took effect, so they stayed tracked on main as well. Local goalplan state is agent scratch data and does not belong in the repository. Files remain on disk; only the index entries are removed.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
💤 Files with no reviewable changes (2)
📝 WalkthroughWalkthroughChangesResponses API authentication
Release metadata
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant ResponsesRequest
participant requireResponsesApiAuth
participant hasValidApiAuth
participant ProxyAdmissionSecrets
ResponsesRequest->>requireResponsesApiAuth: submit request credentials
requireResponsesApiAuth->>hasValidApiAuth: validate supported auth headers
hasValidApiAuth->>ProxyAdmissionSecrets: compare configured secrets
ProxyAdmissionSecrets-->>hasValidApiAuth: validation result
hasValidApiAuth-->>requireResponsesApiAuth: valid or invalid
requireResponsesApiAuth-->>ResponsesRequest: admit request or return 401
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![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: ca14005c3e
ℹ️ 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".
| if (!isApiAuthRequired(config)) return null; | ||
| const actual = req.headers.get("x-opencodex-api-key")?.trim(); | ||
| if (actual && isProxyAdmissionSecret(actual, config)) return null; | ||
| if (hasValidApiAuth(req, config)) return null; |
There was a problem hiding this comment.
When a remote direct-mode client sends its upstream Codex credential in Authorization and the proxy credential in the newly supported x-api-key, hasValidApiAuth selects the nonempty Authorization value first and compares only that value, so the valid x-api-key is ignored and this gate returns 401. The same problem occurs whenever an invalid higher-priority header accompanies a valid lower-priority one; accept the request when any supported admission header matches rather than selecting the first nonempty header.
AGENTS.md reference: AGENTS.md:L65-L71
Useful? React with 👍 / 👎.
| { | ||
| "name": "@bitkyc08/opencodex", | ||
| "version": "2.7.35", | ||
| "version": "2.7.40", |
There was a problem hiding this comment.
Once this feature commit is promoted to main, attempting to release 2.7.40 through scripts/release.ts reaches npm version 2.7.40 --no-git-tag-version with the package already at that version and exits with Version not changed before the release commit or workflow dispatch. Local npm version --help confirms that accepting the same version requires the opt-in --allow-same-version, which the release script does not pass. Revert this unrelated bump and let the release authority create the dedicated version commit after its preflight checks.
AGENTS.md reference: AGENTS.md:L19-L22
Useful? React with 👍 / 👎.
| * Codex Direct. Remote binds must use the dedicated proxy header so the two bearer | ||
| * domains can never be confused. | ||
| * Admission for OpenAI Responses transports. | ||
| * Supports OpenAI standard Authorization header (Bearer <token>), x-api-key, and x-opencodex-api-key. |
There was a problem hiding this comment.
This adds user-facing support for x-api-key, but the remote-access sections in README.md and docs-site/src/content/docs/reference/configuration.md still direct clients to x-opencodex-api-key and do not mention this new alternative; several translated configuration pages likewise state that clients must use the dedicated header. Update the English source and translations so users of standard integrations can discover the behavior and the locales no longer contradict it.
AGENTS.md reference: AGENTS.md:L78-L79
Useful? React with 👍 / 👎.
| if (!isApiAuthRequired(config)) return null; | ||
| const actual = req.headers.get("x-opencodex-api-key")?.trim(); | ||
| if (actual && isProxyAdmissionSecret(actual, config)) return null; | ||
| if (hasValidApiAuth(req, config)) return null; |
There was a problem hiding this comment.
When a non-loopback request selects a Cursor provider without provider.apiKey and authenticates through the newly accepted Authorization: Bearer <proxy-secret>, this gate admits the request, headersForCodexAuthContext preserves that header, and resolveCursorToken uses it as the Cursor access token before the transport sends it upstream. This exposes OPENCODEX_API_AUTH_TOKEN or a dashboard-generated admission key to the Cursor endpoint and still fails authentication there; strip recognized admission credentials before adapter forwarding or retain a separate admission header for routes that consume caller bearers.
AGENTS.md reference: AGENTS.md:L65-L71
Useful? React with 👍 / 👎.
2 participants
Summary
When
opencodexis bound to a non-loopback address (remote mode whereisApiAuthRequiredistrue), therequireResponsesApiAuthhelper previously only accepted the customx-opencodex-api-keyheader.Standard OpenAI SDKs and third-party client integrations (such as Cursor, LangChain, or direct HTTP clients) authenticate using the standard
Authorization: Bearer <API_KEY>orx-api-keyheaders. As a result, standard OpenAI-compatible client requests to/v1/responses,/v1/chat/completions, and/v1/responses/compactwere rejected with a 401authentication_error("opencodex API key required").Change: Updated
requireResponsesApiAuthto usehasValidApiAuth(req, config), which supports the standardAuthorization: Bearer <token>header,x-api-key, andx-opencodex-api-key.Verification
bun run typecheck— cleanbun run test— all tests passtests/server-auth.test.tsverifying thatrequireResponsesApiAuthaccepts standardAuthorization: Bearer <token>,x-api-key, andx-opencodex-api-keyon non-loopback bindings.Checklist
dev.Summary by CodeRabbit
Bug Fixes
Authorization: Bearerandx-api-keycredentials are now accepted alongside supported OpenCode API keys.Release