What version of the Codex App are you using?
Microsoft Store package OpenAI.Codex 26.715.8383.0; bundled app-server 0.145.0-alpha.27.
What subscription do you have?
Exact tier omitted because this is a local connector/authentication failure.
What platform is your computer?
Windows 11 25H2, Microsoft Windows NT 10.0.26200.0, x64.
Component
openai-developers plugin 1.2.3, OpenAI Platform connector.
What issue are you seeing?
The OpenAI Platform connection can appear as Connected, but the secure API-key setup cannot use that authenticated state. The flow alternates between “authentication accepted; retry” and “this app connection requires reauthentication”. The Settings UI eventually shows a generic connection-configuration error and returns to Reconnect.
The sanitized Desktop log identifies a concrete OAuth callback failure:
status=400 routePattern=/aip/connectors/links/oauth/callback
OAuth failed: invalid_request ... go-jose/go-jose: error in cryptographic primitive
Subsequent setup attempts repeatedly fail with:
resources/read failed for codex_apps
(internal://openai-platform-codex-api-key-setup)
MCP error -32603: Failed to read resource
No API key was created, and no secret is included in this report.
What steps can reproduce the bug?
- Open Codex Desktop on Windows.
- Install or enable OpenAI Developers
1.2.3.
- Connect OpenAI Platform and complete authentication.
- Observe that the plugin can display Connected.
- Run “Create an OpenAI API key to use in this project”.
- Authentication is reported as accepted and the tool asks to retry.
- Retry the tool call.
- The call reports that reauthentication is required.
- Reopen Settings: a generic configuration-error banner is shown and the plugin returns to Reconnect.
- Restart Codex, reconnect and retry; the same sequence occurs.
The separate local destination confirmation succeeds for a Git-ignored .env.local. Calling encrypted key creation directly still fails because the connector is considered unauthenticated.
What is the expected behavior?
A successful OpenAI Platform authentication should remain usable by the target picker and encrypted key-creation tool. If the OAuth callback is rejected, Codex should display the underlying reason and a correlation ID rather than showing a transient Connected state and a generic retry loop.
Additional information
Impact:
- Secure key provisioning through Codex is completely blocked.
- Repeated restarts and reconnections do not help.
- The generic UI error gives no actionable diagnosis.
- End-to-end testing of an OpenAI-backed application is delayed.
Related but different reports:
In this case the destination form succeeds; the callback itself returns HTTP 400 with the go-jose cryptographic error.
What version of the Codex App are you using?
Microsoft Store package
OpenAI.Codex 26.715.8383.0; bundled app-server0.145.0-alpha.27.What subscription do you have?
Exact tier omitted because this is a local connector/authentication failure.
What platform is your computer?
Windows 11 25H2,
Microsoft Windows NT 10.0.26200.0, x64.Component
openai-developersplugin1.2.3, OpenAI Platform connector.What issue are you seeing?
The OpenAI Platform connection can appear as Connected, but the secure API-key setup cannot use that authenticated state. The flow alternates between “authentication accepted; retry” and “this app connection requires reauthentication”. The Settings UI eventually shows a generic connection-configuration error and returns to Reconnect.
The sanitized Desktop log identifies a concrete OAuth callback failure:
Subsequent setup attempts repeatedly fail with:
No API key was created, and no secret is included in this report.
What steps can reproduce the bug?
1.2.3.The separate local destination confirmation succeeds for a Git-ignored
.env.local. Calling encrypted key creation directly still fails because the connector is considered unauthenticated.What is the expected behavior?
A successful OpenAI Platform authentication should remain usable by the target picker and encrypted key-creation tool. If the OAuth callback is rejected, Codex should display the underlying reason and a correlation ID rather than showing a transient Connected state and a generic retry loop.
Additional information
Impact:
Related but different reports:
In this case the destination form succeeds; the callback itself returns HTTP 400 with the
go-josecryptographic error.