Codex Desktop startup delayed by Statsig bootstrap schema error for user.custom.workspace_type=null

What happened

Codex Desktop on macOS shows a visible startup delay before the renderer routes mount. The native window and main frame are ready quickly, but the app UI is blocked for ~4.5-6.5s by the post-login Statsig bootstrap path.

The recurring error immediately before route mount is:

Statsig: error while bootstrapping post-login client
path: ["user", "custom", "workspace_type"]
expected string/number/boolean/array/undefined, received null

Environment

• Codex Desktop app: 26.609.30741
• Bundled Codex: 149.0.7827.54
• macOS: 26.5.1, arm64
• App location: /Applications/Codex.app
• Log directory: ~/Library/Logs/com.openai.codex/YYYY/MM/DD

Startup timing evidence

Across multiple cold starts, the main process/window is fast:

window ready-to-show: ~140-154ms
window main frame finished load: ~145-164ms

Initial local app-server calls are also fast:

remoteControl/status/read: 4ms
account/read: 4ms
fs/readFile: 5ms
thread/list: 21ms

The renderer routes mount only after several seconds:

[startup][renderer] app routes mounted after 4508ms
[startup][renderer] app routes mounted after 4843ms
[startup][renderer] app routes mounted after 5791ms
[startup][renderer] app routes mounted after 6494ms

In each run, the Statsig bootstrap error above appears before route mount.

What I inspected

Looking at the packaged app code in /Applications/Codex.app/Contents/Resources/app.asar, the post-login Statsig bootstrap path appears to use a 5000ms timeout:

Timed out while fetching post-login Statsig bootstrap

The startup path renders through a CodexStatsigProvider gate while async Statsig initialization is loading, so this failure path appears to block route mount until bootstrap returns/errors/falls back.

The local Statsig user custom payload assembled by the client includes fields such as workspace_id, plan_type, compute_residency, systemName, systemVersion, codex_window_type, codex_build_flavor, and codex_app_session_id. I did not find the client locally adding workspace_type, so workspace_type: null appears to come from the returned bootstrap payload or another remote-derived user object.

Expected behavior

A null workspace_type value in the post-login Statsig bootstrap payload should not delay app startup for several seconds. Either the payload should omit the field / send a supported value, or the client schema should tolerate null and continue without blocking route mount.

Actual behavior

The app waits several seconds during startup, logs the schema error for user.custom.workspace_type, then falls back and mounts routes.

Notes

I also disabled optional local features/plugins/MCP servers in ~/.codex/config.toml while debugging. That removed earlier slow plugin/app/MCP enumeration calls, but this Statsig bootstrap delay remained. mcpServerStatus/list is now only a few ms in the affected runs, so it does not appear to be the remaining root cause.