[CLI][TUI] Session resume can fail with 'already has an active writer' after approval-mode use or session switching

What issue are you seeing?

Resuming an existing Codex CLI/TUI session can fail with an already has an active writer error, even when I expect the session to be available for continuation.

I have observed this after previously using --not-so-yolo / --approve-for-me, as well as after switching between sessions in the TUI. I am not claiming those modes are necessarily the root cause, only that they are contexts in which the failure has occurred.

The error looks like:

Error: Failed to resume session from .../rollout-...jsonl:
thread/resume failed during TUI bootstrap:
thread/resume failed: thread <THREAD_ID> already has an active writer (code -32600)

This is not Windows-specific. I have reproduced the same resume failure on both Windows and a Linux server.

The session itself still exists, but Codex refuses to resume it because the thread is considered to have an active writer.

What steps can reproduce the bug?

The exact trigger is not fully isolated yet, but I have seen it in these flows:

1. Start and use an interactive Codex CLI/TUI session.
2. Use --not-so-yolo / --approve-for-me, or switch between sessions from the TUI.
3. Later attempt to resume the previous session with codex resume or through the TUI.
4. Codex fails during TUI bootstrap with thread <THREAD_ID> already has an active writer (code -32600).

What is the expected behavior?

If no other client is actively writing to the thread, Codex should allow the existing session to be resumed normally.

If another writer really is active, Codex should identify the owning process/session clearly enough for the user to understand what is holding the thread and recover safely.

Additional information

The same failure has occurred across more than one environment, so it does not appear to be specific to Windows path handling or the Windows /resume picker.

No source files or tests are named. Start by reproducing the failure with codex resume and through the TUI after approval-mode use or session switching, then trace the TUI bootstrap path that reports the active-writer error. Done means a session with no other active writer resumes normally, while a genuinely active writer is identified clearly.