TUI fork keeps the parent thread's writer active, preventing resume from another TUI

Codex version

codex-cli 0.147.0

Environment

• macOS 26.4.1 (25E253)
• Apple Silicon (arm64)
• zsh 5.9
• Installed via @openai/codex

Description

After forking an active thread from the Codex TUI, the original parent thread remains owned by the same TUI/app-server process as an active writer.

As a result, attempting to resume the parent thread from another TUI fails with:

Failed to resume session from ~/.codex/sessions/.../rollout-<timestamp>-<parent-thread-id>.jsonl: thread/resume
failed during TUI bootstrap: thread/resume failed: thread <parent-thread-id> already has an active writer (code -32600)

The fork itself succeeds and the child thread is usable. However, forking does not appear to release or unload the parent thread's writer.

### Steps to reproduce

1. Start Codex TUI and create or resume a thread.
2. Complete a turn in the parent thread.
3. Use the TUI fork flow to fork it into a new thread.
4. Continue working in the forked child thread.
5. Keep the original TUI process running.
6. From another terminal, run:

   codex resume <parent-thread-id>

7. Observe that resume fails because the parent thread still has an active writer.

### Expected behavior

After the TUI switches to the forked child thread and no turn is running on the parent, the parent thread's writer should be released so that another Codex
client can resume it.

If retaining ownership is intentional, the UI should make this behavior clear and ideally provide a way to explicitly unload/release the parent thread.

### Actual behavior

The parent remains locked for the lifetime of the original TUI process, even though the active work has moved to the forked child.

The parent becomes resumable only after terminating the original TUI process.

### Diagnostics

The child rollout metadata confirms that this was a real fork:

{
  "originator": "codex-tui",
  "source": "cli",
  "history_mode": "paginated",
  "forked_from_id": "<parent-thread-id>",
  "history_base": {
    "thread_id": "<parent-thread-id>",
    "end_ordinal_exclusive": 286,
    "end_byte_offset": 4185791
  }
}

While the error was occurring, lsof showed that the original Codex TUI process still had the parent rollout file open for writing:

codex <pid> ... 61u REG ... ~/.codex/sessions/.../rollout-...-<parent-thread-id>.jsonl

The process holding the file was the original codex-tui process attached to the first terminal. A separate local app-server process was checked and had no
rollout files open.

After terminating only the original TUI process, lsof reported no holder and codex resume <parent-thread-id> succeeded.

### Additional context

The forked thread uses paginated history backed by the parent rollout. Keeping the parent available as a read-only history base may be necessary, but retaining
its active writer appears unnecessary and prevents legitimate resume operations from another client.

Start with the TUI fork flow and the parent thread writer lifecycle, then reproduce the issue by forking a thread and running codex resume <parent-thread-id> from another terminal. Use the reported lsof evidence and the resume failure to verify that the parent writer is released after switching to the child while the parent remains available as read-only history.