[codex] Fix OpenAPI multi-key auth inputs#1151
Conversation
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-marketing | f8c383c | Commit Preview URL Branch Preview URL |
Jun 26 2026, 09:13 PM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
executor-cloud | f8c383c | Jun 26 2026, 09:14 PM |
Cloudflare previewTorn down — the PR is closed. |
Greptile SummaryFixes OpenAPI-derived multi-header API key auth (regression case: Cloudflare
Confidence Score: 4/5Safe to merge; core auth derivation and modal UI are correct and well-tested. The fix is narrowly scoped: multi-header paths get unique variable names, single-header paths are untouched. The E2E scenario and real-spec test cover the Cloudflare regression end-to-end. The one minor nit is tautological isVisible() assertions in the browser test after waitFor() calls already confirm visibility. No files require special attention; add-account-modal.tsx has the broadest surface area but the change is a clean branch split with no shared-state mutation. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[OpenAPI spec parsed] --> B{secretHeaders count}
B -- "= 1 single-header" --> C[variablesForHeaders returns empty map]
B -- "greater than 1 multi-header" --> D[variablesForHeaders returns slugified map]
C --> E[placement has no variable property]
D --> F[placement gets variable = slugifyHeader name]
E --> G[singleInput = true]
F --> H[singleInput = false]
G --> I[Single password input, conventional token variable, PlacementLine preview shown]
H --> J[Grid of labeled password inputs one per header, PlacementLine preview hidden]
I --> K[payload values = token]
J --> L[payload values = x_auth_email x_auth_key etc]
K --> M[addConnection API call]
L --> M
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
A[OpenAPI spec parsed] --> B{secretHeaders count}
B -- "= 1 single-header" --> C[variablesForHeaders returns empty map]
B -- "greater than 1 multi-header" --> D[variablesForHeaders returns slugified map]
C --> E[placement has no variable property]
D --> F[placement gets variable = slugifyHeader name]
E --> G[singleInput = true]
F --> H[singleInput = false]
G --> I[Single password input, conventional token variable, PlacementLine preview shown]
H --> J[Grid of labeled password inputs one per header, PlacementLine preview hidden]
I --> K[payload values = token]
J --> L[payload values = x_auth_email x_auth_key etc]
K --> M[addConnection API call]
L --> M
Reviews (1): Last reviewed commit: "Fix OpenAPI multi-key auth inputs" | Re-trigger Greptile |
| "the modal renders one secret input for each required header", | ||
| ).toBe(2); | ||
| expect( | ||
| await dialog.getByPlaceholder("paste X-Auth-Email").isVisible(), | ||
| "email has its own input", | ||
| ).toBe(true); | ||
| expect( | ||
| await dialog.getByPlaceholder("paste X-Auth-Key").isVisible(), | ||
| "API key has its own input", | ||
| ).toBe(true); |
There was a problem hiding this comment.
Tautological visibility assertions after
waitFor()
waitFor() with its default state ("visible") already confirms each element is present and visible. The two isVisible() checks below add no assertion value and do not improve failure messages over the waitFor() lines above them. Per the AGENTS.md quality bar ("no tautologies — don't assert what the setup already guarantees"), these can be removed; the count() assertion plus waitFor() already pin the exact UI state the test needs to prove.
Context Used: e2e/AGENTS.md (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
Summary
Fixes OpenAPI-derived API key auth methods that require multiple header credentials, using Cloudflare legacy auth as the regression case.
Root cause: the OpenAPI auth derivation treated every header in one detected header preset as the same implicit
tokeninput. That preserved both outbound header placements, but the connection modal correctly grouped them into one credential field because both placements referenced the same variable.Changes
tokeninput.X-Auth-Email+X-Auth-Key.Recording
Validation
bunx vitest run src/sdk/real-specs.test.tsinpackages/plugins/openapibun run testinpackages/plugins/openapibun run typecheckinpackages/plugins/openapibunx vitest run src/components/add-account-modal.test.tsinpackages/reactbunx vitest run --project cloud scenarios/openapi-multi-key-auth-ui.test.tsine2ebunx vitest run --project selfhost scenarios/openapi-multi-key-auth-ui.test.tsine2ebunx tsc --noEmitine2ebunx oxfmt --check packages/react/src/components/add-account-modal.tsx e2e/scenarios/openapi-multi-key-auth-ui.test.ts packages/plugins/openapi/src/sdk/derive-auth.ts packages/plugins/openapi/src/sdk/real-specs.test.ts .changeset/openapi-multi-key-auth.mdgit diff --check -- packages/react/src/components/add-account-modal.tsx packages/plugins/openapi/src/sdk/derive-auth.ts packages/plugins/openapi/src/sdk/real-specs.test.ts e2e/scenarios/openapi-multi-key-auth-ui.test.ts .changeset/openapi-multi-key-auth.md