[Bug]: Windows: Codex provider probe exceeds the 10 s AUTH_PROBE_TIMEOUT on ~1 in 4 runs and flips the card to error until the next refresh

What happened

On Windows the Codex provider card intermittently flips to error — toast "Codex provider status: Timed out while checking Codex app-server provider status." — even though Codex is installed, logged in (ChatGPT Pro) and works. It stays in that state until the next health refresh (5 min by default), and it happens most reliably right after app start or a renderer reload, when all providers probe at once.

Diagnosis

checkCodexProviderStatus (apps/server, //#region src/provider/Layers/CodexProvider.ts in the shipped bundle) runs probeCodexAppServerProvider — spawn codex app-server (via the npm .cmd shim on Windows → node → native exe), initialize, account/read, then skills/list + the full model listing — inside a single timeoutOption(AUTH_PROBE_TIMEOUT_MS) with AUTH_PROBE_TIMEOUT_MS = 1e4 (10 s, src/provider/providerSnapshot.ts). On timeout it returns status: "error", auth: unknown, models = custom-only, discarding the previous good snapshot.

Measured on this machine today (server.trace.ndjson, probeCodexAppServerProvider / checkCodexProviderStatus):

2 of 8 probes exceed the 10 s bound; the others take 1.7–5 s, so the bound is within normal variance for this platform under load (5 providers probing concurrently + the known 5 s editor-discovery block, #4697).

Suggested fix (small): either raise AUTH_PROBE_TIMEOUT_MS on Windows (or overall), or on timeout keep the last known-good snapshot and mark it stale (status "warning", "Codex probe timed out; showing last known status") instead of flipping to error with an empty model list.

Steps to reproduce

1. Windows desktop app, Codex installed via npm (@openai/codex 0.148.0, ChatGPT login).
2. Start the app (or reload the renderer) so all provider probes run concurrently.
3. Watch caches/codex.json / the Codex card: roughly 1 in 4 probes lands at status: "error", message "Timed out while checking Codex app-server provider status.", until the next 5-minute refresh.

Version

0.0.34-nightly.20260819.1132 (commit 36f4314ab768).

Environment

Windows 11 Pro 10.0.26100, Node 24.11.1, @openai/codex 0.148.0 (npm, via %APPDATA%\npm\codex.cmd), ChatGPT Pro login.

Evidence

# caches/codex.json after the 08:53:16 probe
{"status":"error","installed":true,"version":null,"auth":{"status":"unknown"},
 "message":"Timed out while checking Codex app-server provider status.","checkedAt":"2026-08-19T08:53:16.976Z"}

# bundle
const AUTH_PROBE_TIMEOUT_MS = 1e4;
... probe({...}).pipe(scoped$1, timeoutOption(millis(AUTH_PROBE_TIMEOUT_MS)), result$1)
... if (isNone(probeResult.success)) return buildServerProvider({ ... status: "error", auth: { status: "unknown" }, message: "Timed out while checking Codex app-server provider status." })

Related issues

#4697 / #5137 (editor discovery blocking server.getConfig for 5 s on Windows) is the likely source of the concurrent load, but this is about the provider probe's own bound and error handling; no existing issue mentions the Codex probe timeout.

Fix applied or workaround

None locally (the timeout is a constant). It self-heals at the next 5-minute refresh or on a settings change.

Filed by

Claude (Fable 5) via Claude Code on the reporter's machine, at the reporter's request.

Start with src/provider/providerSnapshot.ts and the CodexProvider.ts implementation of checkCodexProviderStatus and probeCodexAppServerProvider. Trace the AUTH_PROBE_TIMEOUT_MS handling and timeout result, then verify the chosen behavior preserves or reports the last known status without incorrectly showing an error or empty model list.