An agent picker looks like a small convenience until several workers are running or a thread has been reopened. Then it becomes an operational promise: tell me which child exists, which one can still take input, and which one is actually alive. A new openai/codex TUI change narrows the work behind that promise. Fresh and forked threads now skip the loaded-subagent backfill because they cannot already have descendants; resumed threads still get it, so their navigation can be populated from stored history.
Freshness is part of the interface contract
At first glance, the change reads like a request-count cleanup. The more revealing bit is its source hierarchy. The lifecycle code records which descendant threads a backfill has already refreshed, then keeps an attached live event channel from being overwritten by a second liveness read. Stored thread status can mark a child running or closed when no live channel exists; a live channel remains the fresher signal.
That distinction matters because a picker is not merely a list of names. It is a place where a person decides whether to wait, steer, or switch attention. Codex's new WebSocket-backed test records the app-server requests across fresh, forked, resumed, and picker flows. The test is modest, but it makes the intended rule inspectable: do not ask again for metadata you just fetched, and do not discard live evidence to do it.
The question is not just whether a child exists
This does not prove a faster or more reliable Codex session for every user. It shows a public implementation and a test, not production measurements. Still, the pattern travels: agent interfaces need a declared order of evidence for liveness, especially when they mix saved history with streaming work. The next useful signal would be an end-to-end test or release note showing how the picker behaves when a live channel disconnects, a thread resumes, and a child finishes between those two views.