Resuming a fresh thread from a second client fails before its first message

Hi! I’m working on amux, a terminal session manager that uses Codex’s app-server to create and manage conversations. I’d like users to create a conversation and then attach the standard Codex TUI to it, without having to send a message first.

On codex-cli 0.153.4, I’m seeing an issue with this workflow:

1. My app-server client creates a non-ephemeral, paginated thread using thread/start.
2. Before any message is sent, the standard Codex TUI connects to the same server and resumes that thread by ID.
3. The TUI exits during startup with:

   invalid paginated history lineage ... missing source rollout
   

The thread remains usable through the original client. Sending a message there makes subsequent TUI attachment work. Naming the thread does not resolve the failure.

From reading the server code, it appears that the server finds the live thread but fails while building its resume response. The TUI requests excludeTurns: true, which skips saving the thread’s history file. However, the server still constructs pagination cursors that need that file.

I’ve verified a workaround: my creating client first calls thread/resume on the same thread with excludeTurns: false. After that, TUI attachment and reattachment work without any model turn, and the same thread can also be resumed after restarting the app-server.

Could the server save the history file before constructing those cursors, including when excludeTurns: true? That would let the TUI’s own resume request succeed immediately after thread/start, without requiring the extra resume call from my client.

I understand that external PRs aren’t currently accepted. Would you prefer to handle this internally, or would a small, focused PR with a regression test be welcome for this case?

Thanks for considering it!

Start with the app-server handlers for thread/start and thread/resume, focusing on the excludeTurns: true path and pagination cursor construction. Reproduce by creating a non-ephemeral thread, attaching the TUI before its first message, and checking the missing source rollout error. Done means immediate TUI resume succeeds and a regression test covers the fresh-thread workflow.