Add Codex device-code sign-in

[Pedromdsn]

Summary

• Add a Codex Device Code provider sign-in option alongside existing Codex OAuth.
• Reuse existing Codex secure credential storage, profile activation, and runtime routing.
• Update provider validation hints and ProviderManager preset ordering.

Test plan

• bun run build
• bun test src/commands/provider/provider.test.tsx src/components/ProviderManager.test.tsx src/utils/providerValidation.ts
• bun test src/services/api/providerConfig.codexSecureStorage.test.ts src/services/api/providerConfig.runtimeCodexCredentials.test.ts src/utils/codexCredentials.test.ts
• Device-code behavior probe for standard parse, malformed response, and access_denied handling

Notes

• Full bun test has unrelated environment-sensitive failures in StartupScreen.test.ts and sdk-context-isolation.test.ts when Codex/OpenAI env vars are set locally; those tests pass when the Codex env is unset.
• Repository-wide bun run typecheck currently fails with unrelated baseline errors outside these changed files.

[Copilot]

Pull request overview

Adds a new Codex “device code” sign-in path alongside the existing Codex OAuth flow, reusing the same secure credential storage and Codex runtime activation behavior.

Changes:

• Introduce a Codex device-code API flow (device-code request + token polling) and a React hook to drive the UI flow and persistence.
• Add “Codex Device Code” as a selectable option in both ProviderManager and /provider wizard flows.
• Update provider validation hints and preset ordering expectations.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/utils/providerValidation.ts	Updates Codex auth validation hints to mention device-code sign-in.
src/services/api/codexDeviceFlow.ts	Adds device-code request/polling implementation for Codex auth.
src/components/useCodexDeviceCodeFlow.ts	Adds React hook orchestrating device-code sign-in, browser open, polling, and secure persistence.
src/components/ProviderManager.tsx	Adds a new “Codex Device Code” setup screen and preset option.
src/components/ProviderManager.test.tsx	Updates preset ordering expectations to include “Codex Device Code”.
src/commands/provider/provider.tsx	Adds a new /provider wizard step for Codex device-code sign-in.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[kevincodex1]

please address copilot's comments

[jatmn]

Additional Review Response for PR #1045

1. Missing interval is treated as a hard failure

File: src/services/api/codexDeviceFlow.ts

The current device-code response parser rejects otherwise valid successful responses when the provider omits interval. That behavior is inconsistent with the rest of the implementation, which already falls back to a default polling interval of five seconds when interval is absent or non-positive. In practice, this means legitimate device-code sign-in attempts can fail immediately even though the flow already has a safe default.

I recommend accepting responses that omit interval and normalizing that case to the existing five-second fallback.

2. Device-code reauthentication creates redundant Codex profiles

File: src/components/ProviderManager.tsx

The new device-code branch always creates a fresh provider profile instead of reusing the stored Codex-linked profile when one already exists. This differs from the existing Codex OAuth implementation, which updates the prior profile in place. The surrounding credential model still appears to treat Codex secure storage as a single linked login with a single associated profile id, so repeated device-code sign-ins create redundant Codex profiles even though the underlying secure store only tracks one linked profile. The current logout and delete cleanup paths then only follow the most recently stored profile id.

I recommend mirroring the existing OAuth behavior by resolving the stored Codex-linked profile first and updating it when present instead of always creating a new profile.

3. slow_down without an interval does not increase the polling delay

File: src/services/api/codexDeviceFlow.ts

When the token endpoint returns slow_down without an accompanying interval, the polling loop continues at its previous cadence rather than backing off. This can leave the client in a repeated rate-limited state and makes the device-code flow less resilient under real-world server behavior.

I recommend applying a default backoff increase for slow_down even when the response does not provide an explicit interval, such as increasing the current interval by five seconds.

Conclusion

These issues appear reasonably contained, but I recommend addressing them before merge. The first can cause the new sign-in path to fail outright, while the latter two introduce avoidable long-term behavior issues in repeated or rate-limited authentication flows.