Codex App: make session-status checks feel instant

Summary

The Codex app feels slow in the core loop before model or tool latency is involved. Checking whether a session is running, opening an existing session, or seeing that a session has finished should feel close to opening Instagram: show a useful state immediately, then progressively load detail.

This is a Codex App responsiveness issue, not a request to optimize model generation.

User-visible flows

• Launch the app and see the session list and current statuses.
• Switch to an existing session.
• Resume a session and see whether it is running, waiting, or finished.
• Return to the app after a background refresh or reconnect.
• Confirm that a session has completed without waiting for full history hydration.

Evidence already in the tracker

• #45636 reports 10–15 seconds to open chats.
• #37334 reports minutes to tens of minutes before threads become interactive.
• #38373 measures a 1.87-second full scan of a 23,739-thread state table during startup.
• #40137 measures a roughly 2.5-second stale model-metadata fetch on the first-turn critical path.
• #42812 reports a 55% reduction in a local filesystem metadata repro after removing redundant home-directory resolution.

Proposed behavior

1. Render the latest locally available session status from an indexed/cacheable source before hydrating full conversation history.
2. Keep model, MCP, plugin, and other network refreshes off the first usable status path when cached state is sufficient.
3. Make history hydration progressive and cancellable; opening a session should not require scanning or rendering all of its contents first.
4. Use explicit loading/stale/reconnecting states so an immediate status is useful without implying it is final.
5. Define and publish latency budgets. As a starting point, target the first useful session state within 500 ms on warm local state and within 2 seconds on cold start, then tighten based on measured baselines.

Acceptance criteria

• The four flows above have p50/p95 measurements split by cold/warm start and local history size.
• The first useful session status meets an agreed budget without waiting for full history hydration or optional network refreshes.
• Large histories do not make the common status-check path degrade linearly.
• Regressions are covered by an automated performance check or trace-based benchmark.

Related

See #40087 for per-turn/tool timing. This issue focuses specifically on the user-visible session-status path.

No files, tests, or entry points are named. Start by locating the session-status path and measuring the four listed flows across cold and warm starts; done means an agreed first-useful-status latency budget is met without full history or optional network refreshes, with large-history regressions covered by a performance check or trace benchmark.