[Bug]: macOS: Codex provider probe intermittently exceeds the 10 s AUTH_PROBE_TIMEOUT and latches the card as error #18879

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run the T3 Code desktop app on macOS with the Codex provider enabled (binaryPath = /opt/homebrew/bin/codex, ChatGPT account).
2. Let provider health checks run — at app launch or while the host is under load.
3. Open Settings → Providers (or the composer model picker): the Codex card shows Timed out while checking Codex app-server provider status. and stays that way.

Expected behavior

A slow-but-healthy probe run should degrade gracefully — keep the last known-good snapshot or retry — instead of flipping Codex to Unavailable on a single timeout.

Actual behavior

checkCodexProviderStatus wraps a whole short-lived codex app-server session (spawn + initialize + account/read + skills/list + model/list + account/rateLimits/read) inside one hardcoded 10 s AUTH_PROBE_TIMEOUT_MS. On this machine probeCodexAppServerProvider spans in ~/.t3/userdata/logs/server.trace.ndjson* take 1.7–8.2 s when they succeed — one success at 8165 ms — and two spans were interrupted at ~26.2 s inside withCodexAppServerClient. Any single run past 10 s fails with Timed out while checking Codex app-server provider status., and per #7230 the result latches as status: "error" until a later probe happens to land under the budget, so the card reads Unavailable for long stretches.

Replaying the same JSON-RPC sequence standalone with the host idle takes ~1.25 s total, so the CLI is healthy — the margin is just thin whenever the spawn or app-server's startup catalog refresh stalls (it refreshes models_cache.json online at startup).

Same budget problem as #7513 (Windows, ~1-in-4 runs) and #8955 (WSL cwd on drvfs); this is the macOS desktop variant, where the T3 server's process.cwd() is $HOME. Related latch: #7230. The fix direction mirrors #11080 / PR #16544 for OpenCode: a larger budget for the full-session probe (or per-request sub-timeouts like rateLimits already has), plus keeping last-known-good on timeout.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261013.3040

Environment

macOS 27.0.1 (Darwin 27, arm64), T3 Code Nightly desktop. Codex CLI 0.162.1, native arm64 Mach-O at /opt/homebrew/bin/codex (no shim), ChatGPT auth. Proxy env (HTTPS_PROXY=http://127.0.0.1:7897) is present in the T3 server process environment.

Logs or stack traces

# probeCodexAppServerProvider spans from ~/.t3/userdata/logs/server.trace.ndjson.*
server.trace.ndjson.1  dur=2378ms   Success
server.trace.ndjson.3  dur=8165ms   Success
server.trace.ndjson.3  dur=26235ms  Interrupted  (inside withCodexAppServerClient)
server.trace.ndjson.3  dur=26237ms  Interrupted  (inside withCodexAppServerClient)
server.trace.ndjson.5  dur=1668ms   Success
server.trace.ndjson.8  dur=3163ms   Success
server.trace.ndjson.8  dur=5415ms   Success

# standalone replay of the same request sequence (cwd=/Users/liam, idle host):
#   initialize 0.15s · model/list 0.16s · skills/list 0.18s · account/read 1.18s · rateLimits 1.25s

Workaround

Manually refresh the Codex provider in Settings → Providers while the machine is idle — the probe then finishes in ~1–2 s. There is no user-side timeout override.