app-server atomic join of an already-loaded thread

What variant of Codex are you using?

codex-cli 0.165.0 app-server over a private Unix WebSocket on Linux, with a secondary local client. Reproductions used a scripted Responses provider and no credentials or live model.

What feature would you like to see?

Please provide a supported operation that subscribes to an existing loaded thread without ever cold-loading it, atomically with runtime teardown.

For example, a dedicated thread/subscribe operation or a loaded-only option on resume could guarantee:

• Attach only if that runtime is still loaded and can accept a listener.
• Otherwise return an explicit not-loaded/closing result, without restoring the thread from its rollout or changing settings.
• Replay the currently pending server requests after successful attachment, with the usual request identity and response behavior.
• Serialize attachment against last-listener removal and unload. An optional runtime-instance condition would also let a client reject replacement of the runtime it observed.

The API name is illustrative; the important property is that checking and attaching form one server-side operation. It should start no turn and preserve the existing unsubscribe behavior. A client should not need to hold an idle runtime loaded merely to make future attachment safe.

Additional information

A secondary client may need to handle a pending user-input request while avoiding unrelated or idle runtimes. Current loaded discovery, status broadcasts and resume provide useful pieces, but client-side checks leave a race:

1. The client observes an already-loaded thread, possibly active and waiting for user input.
2. The request settles, other subscribers leave, and the runtime becomes eligible for unloading.
3. Before the client handles the updated status, its resume reaches the server after unload.
4. Resume can restore the thread instead of returning a loaded-only miss.

The 0.165.0 source has an internal path that coordinates listener attachment with teardown, but its public resume parameters do not expose this guarantee. thread/read is passive and does not subscribe; see related issue 17900.

A timeout derived from config/read is not equivalent. In a private 0.165.0 control, the merged thread_unload_delay_secs key reported 60 while a thread started with a supported override of 2 unloaded roughly two seconds after both clients unsubscribed. That config read does not establish the loaded runtime's effective retention bound. Likewise, a fast observed resume is not a guarantee under arbitrary scheduling delays.

Native controls did confirm that an unsubscribed connection receives active/waiting status and that resuming a waiting thread replays its pending request. The requested primitive would let integrations use those capabilities without inadvertently resurrecting an idle thread. No changes to model behavior, answer arbitration, permissions or default unloading policy are requested.