[Windows][OpenAI Developers] Platform OAuth fails with go-jose cryptographic error, then API-key setup loops on reauthentication

Start with the /aip/connectors/links/oauth/callback failure and the codex_apps resource-read path described in the report. Trace how the accepted OAuth state reaches the target picker and encrypted key-creation tool, then verify the flow either remains authenticated or exposes the callback reason and a correlation ID instead of looping through generic retry errors.

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?

1. Open Codex Desktop on Windows.
2. Install or enable OpenAI Developers 1.2.3.
3. Connect OpenAI Platform and complete authentication.
4. Observe that the plugin can display Connected.
5. Run “Create an OpenAI API key to use in this project”.
6. Authentication is reported as accepted and the tool asks to retry.
7. Retry the tool call.
8. The call reports that reauthentication is required.
9. Reopen Settings: a generic configuration-error banner is shown and the plugin returns to Reconnect.
10. 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:

• openai/codex#25157 and openai/codex#25257 cover a Windows protocol callback being interpreted as an Electron path.
• openai/codex#30978 covers the local destination form being auto-declined.

In this case the destination form succeeds; the callback itself returns HTTP 400 with the go-jose cryptographic error.