0.151.0 regression: app-server thread/start no longer persists zero-turn threads, breaking resume

Description

Between @openai/codex 0.150.1 and 0.151.0, thread/start via codex app-server --stdio stopped creating a rollout file until the first turn.

thread/start still returns a valid thread ID and adds it to $CODEX_HOME/session_index.jsonl, but no matching rollout file is created. Attempting to resume that thread therefore fails:

thread/resume failed: no rollout found for thread id <uuid> (code -32600)

The TUI reports the equivalent error:

Failed to resume session from <nonexistent rollout path>

Why zero-turn sessions are useful

This is a workaround for Codex not supporting a caller-supplied session/thread ID.

I want to store each session in a working directory named after its session UUID. Other agents let me generate a UUID first and pass it when starting the session:

uuid=$(uuidgen)
mkdir "$uuid"
claude --session-id "$uuid" --cwd "$uuid"  # grok follows the same pattern

Codex generates the ID internally and exposes no equivalent --session-id option or thread/start parameter.

To obtain the ID before sending the first real turn, I therefore have to use this sequence:

1. Start codex app-server --stdio.
2. Send initialize, initialized, and thread/start.
3. Read the generated thread.id.
4. Rename or move the session working directory to that ID.
5. Shut down the app-server.
6. Resume the thread with codex resume <thread_id>.
7. Send the first real turn.

This worked in 0.150.1. In 0.151.0, step 6 fails because the zero-turn thread was indexed but never persisted.

Sending a dummy first turn is not an adequate workaround. The purpose of starting a zero-turn thread is to obtain the generated ID before establishing the final working-directory name and before adding anything to the conversation history.

Related caller-supplied-ID request: #7801. This regression matters independently: thread/start returns and indexes a thread ID that cannot subsequently be resumed.

Minimal reproduction

Start the app-server:

codex app-server --stdio

Send:

{"id":1,"method":"initialize","params":{"clientInfo":{"name":"repro","version":"1"}}}
{"method":"initialized","params":{}}
{"id":2,"method":"thread/start","params":{"cwd":"/tmp/codex-repro","approvalPolicy":"never","sandbox":"workspace-write","serviceName":"repro","threadSource":"cli","sessionStartSource":"startup"}}

Capture the returned thread.id, then stop the app-server.

Check the index and rollout files:

grep '<thread-id>' "$CODEX_HOME/session_index.jsonl"
find "$CODEX_HOME/sessions" -type f -name "*<thread-id>*"

The index contains the thread, but no rollout file exists.

Then run:

codex resume <thread-id>

Result:

thread/resume failed: no rollout found for thread id <thread-id> (code -32600)

Expected behavior

Any of the following would address the use case:

1. thread/start creates enough durable state for the returned thread ID to be resumable, as it did in 0.150.1.
2. An explicit thread/persist, thread/flush, or equivalent RPC is provided.
3. thread/start and the CLI accept a caller-supplied thread/session ID. ( #7801)

At minimum, $CODEX_HOME/session_index.jsonl should not contain a thread that thread/resume cannot resolve.

Actual behavior

thread/start returns and indexes a thread ID, but the thread remains non-resumable until a first turn creates the rollout file.

Regression range

Working: @openai/codex 0.150.1
Broken:  @openai/codex 0.151.0

Environment checks

• $CODEX_HOME is writable.
• Disk space and inodes are available.
• A normal codex exec on the same host creates its rollout file successfully.
• The behavior is specific to the app-server thread/start path.

Reproduce the regression with codex app-server --stdio, the initialize and thread/start requests, and codex resume <thread-id>. Trace the app-server thread/start path and its rollout persistence alongside $CODEX_HOME/session_index.jsonl. Done means a zero-turn thread returned by thread/start has durable state that thread/resume can resolve, with no index entry pointing to a missing rollout.