[Bug]: Desktop startup briefly warns about Codex provider status before its initial check completes #24527

Area

apps/web (desktop startup; initial provider status originates in apps/server)

What happened

T3 Code briefly displays an amber “Personal provider status” notification saying:

Codex provider status has not been checked in this session yet.

The notification disappears as initialization completes. This looks like a provider/configuration problem even though the message describes a check that has not run yet.

Steps to reproduce

Observed on an existing Windows desktop installation with both the local Windows environment and WSL Ubuntu enabled:

1. Close T3 completely.
2. Open T3 Code from the pinned Windows taskbar icon.
3. Watch the initial new-thread screen while providers initialize.
4. A provider-status warning briefly appears, then disappears without intervention.

A locally reviewed recording shows the notification at approximately 5.25 seconds into the recording and no notification at the 6-second sample. Those samples do not establish its exact duration. Frequency and reproduction on a clean installation have not been established.

Expected behavior

Represent an initial provider check as loading/checking, rather than showing a problem-style warning before the check finishes. Show an actionable warning or error when a check actually fails or times out.

Actual behavior

A pending initial state is presented as a warning, giving the impression that authentication or configuration is broken.

Version and environment

• T3 Code desktop 0.1.2, packaged commit 044f072.
• Windows desktop with local Windows and WSL Ubuntu environments enabled.
• Codex provider.
• “WSL only” disabled.

Evidence

The installed server bundle, apps/server/dist/binCli-BQvPfujE.mjs, creates the pending Codex provider snapshot with:

• status: "warning"
• auth: { status: "unknown" }
• The notification message quoted above.

In the inspected 15-second startup trace window, all four Windows-server checkCodexProviderStatus operations ended with Success (durations: 2510.6, 2408.0, 1831.9, and 1692.4 ms). Span success establishes completion of those operations; it is not an end-to-end test of sending a model request.

The connection catalog loaded successfully in both reads during this launch. This warning is therefore separate from the catalog decryption failure discussed in #8341.

For timing context, in this one measured launch, the Windows backend's onReady span completed 2.681 seconds after the recorded desktop startup began; WSL's completed after 8.407 seconds. These are not averages, not timings from the taskbar click, and not evidence of a performance regression. The recording remained on the new-thread screen, so it does not measure opening an existing chat.

Impact

Minor UI issue: a normal initialization state appears to be a provider failure. It is especially confusing when checking whether saved connections and configuration survived a restart.

Related reports and scope

#16932 also mentions a pending-provider notification, but concerns a much longer macOS server stall. This report does not claim the same root cause. Its scope is the warning presentation before the initial Codex check finishes.

No raw logs, recordings, screenshots, personal paths, account details, or chat contents are attached.

Prepared with assistance from Codex from local video, trace, and installed-code inspection.