Repository navigation
Codex provider check times out after 20 s when codex app-server starts slowly #27230
Description
What happened
On first launch of T3 Code, and again when adding the agent later, Codex is not detected. The first error was: Unavailable · Codex app-server provider probe failed: failed to reload config: ….codexconfig.toml:6:16: unknown variant priority, expected fast or flex. That came from an outdated npm install of Codex (0.118.0) and is fixed by updating to 0.166.0. After that, the Codex status permanently shows Unavailable · Timed out while checking Codex app-server provider status. Claude is detected correctly. Codex itself works; only the check fails.
Diagnosis
- The check has a fixed 20 s limit (
CODEX_AUTH_PROBE_TIMEOUT_MSinapps/server/src/provider/CodexProvider.ts, tag v0.1.5). The value is unchanged onmain(commitdd148481, 2026-10-29). - On this machine
codex app-servertakes about 23–24 s to answerinitialize. Process start is slow forcodex(both the npm build and the Codex desktop app's build) and fornode. Small programs (cmd,git,python,java) start in under 0.5 s. - Ruled out: Codex configuration (an empty
CODEX_HOMEchanges nothing), Windows Defender real-time protection (switched off, no change), Defender exclusions fornode.exeandcodex.exe, and network (CRL fetch 0.7 s). - The cause of the slow process starts is not found. The machine is about 10 years old. The user reports that on an earlier attempt T3 Code did not start at all and aborted with an error.
- Confirmed by experiment: a copy of the installed
server.asarwith the limit raised to 60 s, started separately with its own--base-dir, reports Codex asready, authenticated, with models listed. With 20 s the same machine reportsTimed out. - Suggestion: raise the limit for the Codex check or make it configurable. On timeout, the UI should hint at a slow start instead of only showing "Unavailable".
Steps to reproduce
- Use a machine where
codex app-serverneeds more than 20 s to answerinitialize(measure withMeasure-Command { codex --version }). - Start T3 Code and open Settings → Providers → Codex.
- The status shows
Timed out while checking Codex app-server provider status.
No deterministic repro on a fast machine was found. A wrapper that delays codex by more than 20 s should have the same effect (not tested).
Version
0.1.5 (desktop app, local server; nightly 0.1.6-nightly.20261029.3892 could not be activated, main stayed active; limit is also 20 s on main)
Environment
Windows 11 Pro 10.0.22631 x64, Node v24.15.0, codex-cli 0.166.0 (npm global, previously 0.118.0), T3 Code desktop 0.1.5, t3 triage CLI 0.1.5. Machine about 10 years old, 64 GB RAM.
Evidence
Unavailable · Timed out while checking Codex app-server provider status.
codex --version: 22.1 s (npm), 17.7 s (desktop app)
node --version: 4.5 s
apps/server/src/provider/CodexProvider.ts:76 const CODEX_AUTH_PROBE_TIMEOUT_MS = 20_000;
apps/server/src/provider/CodexProvider.ts:775 message: "Timed out while checking Codex app-server provider status."
patched copy with 6e4: status=ready, version=0.166.0, auth=authenticated, models=8
earlier error: unknown variant `priority`, expected `fast` or `flex`Related issues
No issue with the same error found (searched service_tier, unknown variant priority, codex config.toml probe failed). Similar but different: #10576 (Codex Priority display, closed).
Fix applied or workaround
npm install -g @openai/codex@latest(0.118.0 → 0.166.0) fixed the first error.- Defender exclusions and switching real-time protection off for testing did not help and were reverted.
- There is no workaround for the timeout in the installed app, only the experiment with the patched copy.
Filed by
claude (sonnet-5-5) via t3 triage, in Claude Code
Activity
VDrozd-Cyclis commentedon Oct 31, 2026
Same timeout on Linux, intermittent rather than permanent (T3 Code 0.1.6)
Seeing the same
Timed out while checking Codex app-server provider status.message, but intermittently. The server runs on Linux x64 (Debian, in a container limited to 16 CPUs / 24 GB RAM) with the desktop client (0.1.6) connected from macOS. Codex CLI is 0.166.0, authenticated (ChatGPT Pro). The server is T3 Code 0.1.6, a stable release.CODEX_AUTH_PROBE_TIMEOUT_MSis still 20 s in that tag.Server trace,
checkCodexProviderStatusspan durations:codex --versiontakes ~55 ms here, so the binary itself starts fast. The variable part is theapp-serverinitialize handshake (it also spawns Codex plugin MCP processes). The container isn't resource-starved: memory use is 5.6 GB of 24 GB and CPU throttling is ~0.03% of periods. The server's event-loop-stall log shows repeated 2–12 s stalls between Oct 27 and Oct 30, though none today, so I can't tie them to this timeout.This suggests the 20 s limit has little headroom even on a well-provisioned host. A longer or configurable limit, or retrying a timed-out probe before latching the error, would help here as well.
Written by Claude (sonnet-5-5) via
t3 triagein Claude Code.codemanat commentedon Oct 31, 2026
Related finding with the same pattern but a different code path: the Pi provider aborts
pi --versionafter 4 s (VERSION_PROBE_TIMEOUT_MS = 4e3). On my machine the call takes about 5 s, so Pi is reported as unavailable. Details in #28393. This supports making probe timeouts more generous or configurable across providers, rather than using fixed per-provider constants.lord007tn commentedon Nov 2, 2026
This is a second affected Windows setup with the same timeout, and the failure predates the latest T3 update.
0.1.7-nightly.20261102.4061(current/up to date); Codex CLI:0.166.0.Unavailable · Timed out while checking Codex app-server provider status.initializerequests waiting about 20 seconds and timing out before T3 reachesaccount/read; CLIcodex login statusreports ChatGPT login under each account home.This supports the existing diagnosis that the fixed probe deadline is too short on some Windows systems. Please consider making the timeout configurable or using a longer startup deadline, and preserving the distinction between a slow app-server start and authentication failure in the provider status.
Follow-up after tracing the local Codex stderr on November 2: on this setup the T3 timeout was secondary to a stalled Codex state-database backfill. The native app-server reported
state db backfill is runningand exited after its own 30-second startup wait. The saved checkpoint was not advancing because repeated short-lived launches left the backfill claim inrunning.After taking a consistent SQLite backup, releasing the stalled claim while preserving its checkpoint, and allowing one native Codex app-server process to complete the backfill without T3's watchdog, initialization succeeded after about 188 seconds. Subsequent startup/account checks for all three provider instances took 0.36–0.74 seconds, and T3 now reports all three as authenticated. Existing chat records and curated metadata were checked against the backup and preserved.
No T3 package patch or restart was needed for this recovery. A longer probe deadline and surfacing the underlying app-server stderr could still improve diagnosis, but the fixed 20-second deadline was not the complete cause on this machine.
juliusmarminge commentedon Nov 12, 2026
Fixed by #33275, now on main: Set T3CODE_CODEX_PROBE_TIMEOUT_MS=60000 in the T3 server environment and restart: the reported 23–24-second Codex initialization can now complete within the configured status-check and discovery budget without patching the installed application.
Fonsi479 commentedon Nov 13, 2026
Additional observation on T3 Code (Beta) 0.1.9, macOS 27.0 arm64, Codex CLI 0.169.0 with ChatGPT authentication.
The UI showed:
The local T3 server trace captured this sequence (rounded milliseconds):
T3 subsequently reported the same installed provider as ready/authenticated. This was not a missing executable. The shipped 0.1.9 bundle still wraps the overall probe with
CODEX_AUTH_PROBE_TIMEOUT_MS, and the failed check exhausted that budget during account/read.This differs from the original Windows report's 23–24 s initialize: here startup plus account discovery consumed the budget. Network/proxy variability may contribute, but I have not isolated the upstream cause, and I did not verify inference during the failed health-check window.
Please consider this current macOS evidence when deciding whether to reopen this report or track it elsewhere. More actionable timeout details (which stage timed out), a bounded retry, and configurable readiness limits would help. Related: #25499 and #33266.