Skip to content

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

Open
Open
[CLI][TUI] Session resume can fail with 'already has an active writer' after approval-mode use or session switching#39823
Labels
CLIIssues related to the Codex CLITUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@Relic-a
Relic-a
opened on Aug 21, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal display
    windows-osIssues related to Codex on Windows systems
    app-serverIssues involving app server protocol or interfaces
    on Aug 21, 2026

  2. github-actions commented on Aug 21, 2026

    @github-actions
    github-actionsBot
    on Aug 21, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. Relic-a
    changed the title [-][CLI][TUI] Resuming session fails with 'already has an active writer' and Windows CWD filter mismatch[/-] [+][CLI][TUI] Session resume can fail with 'already has an active writer' after approval-mode use or session switching[/+] on Aug 21, 2026

  4. Fireotics commented on Aug 21, 2026

    @Fireotics
    Fireotics
    on Aug 21, 2026

    {"detail":"Bad Request"} Error

  5. shallitbeso
    marked Resume fails with “already has an active writer” after interrupting an approval and restarting with --approve-for-me #40571 as a duplicate of this issue on Aug 25, 2026

  6. shallitbeso commented on Aug 25, 2026

    @shallitbeso
    shallitbeso
    on Aug 25, 2026

    I can reproduce this consistently on Linux with Codex CLI 0.149.1 using the following sequence:

    Start Codex normally.
    Trigger a command that requires manual approval.
    Press Ctrl+C while the approval prompt is open.
    Restart with codex --approve-for-me.
    Resume the interrupted session.
    Resume fails with:
    thread/resume failed during TUI bootstrap:
    thread/resume failed: thread THREAD_ID already has an active writer
    (code -32600)
    Restarting normally without --approve-for-me allows the same session to resume successfully.

  7. Skandesh commented on Aug 25, 2026

    @Skandesh
    Skandesh
    on Aug 25, 2026

    Additional Linux reproduction on Codex CLI 0.149.1 (2026-08-25 UTC).

    I hit the same failure while trying to resume a saved TUI session:

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

    The rollout JSONL is intact and ends with a normal task_complete record. The matching lock file is present at ~/.codex/thread-writer-locks/<THREAD_ID>.lock. Read-only inspection showed that a still-running Codex CLI process held the lock and its write descriptor, so this instance is an active-writer lifecycle/handoff case rather than an unowned lock file. The owning process was an older TUI left running while a new TUI attempted the resume.

    Expected behavior: show the owning client/process, or provide a safe attach, handoff, or read-only recovery path. A duplicate lock-file deletion workaround would risk two writers.

  8. nos1609 commented on Aug 28, 2026

    @nos1609
    nos1609
    on Aug 28, 2026 – with ChatGPT Codex Connector

    I reproduced the exact TUI-bootstrap error on Windows during a cross-surface resume after the Desktop app update.

    Environment:

    • OpenAI.Codex Store package 26.825.3734.0 (Arm64)
    • Standalone codex-cli 0.150.1
    • Windows 11 Pro, build 28000, ARM64
    • The affected rollout was created from the VS Code surface and records CLI version 0.142.5

    The failure is:

    thread/resume failed during TUI bootstrap:
thread/resume failed: thread <redacted> already has an active writer (code -32600)

    A read-only sanitized inspection found the rollout present and parseable: one session_meta, 595 turn_context records, 88,715 JSONL records, and zero invalid JSON lines. I did not modify the database or rollout.

    A writer may still be live in the other surface. The user-visible problem is that the TUI reports only an opaque conflict. It does not identify the owning process or surface, offer observer mode, or provide a safe handoff action.

    I uploaded the affected thread ID and diagnostics privately through /feedback.

    Uploaded thread: 01a0470d-0700-71b0-8afb-875b432c5088

  9. emmett2020 commented on Aug 29, 2026

    @emmett2020
    emmett2020
    on Aug 29, 2026

    I met the same issue when I closed the codex with ctrl-X and then re-enter this codex session with 'resume'.

  10. PhiFever commented on Aug 31, 2026

    @PhiFever
    PhiFever
    on Aug 31, 2026

    Just use

    ps -aux | grep codex

    and kill the old codex process can fix it

  11. hyperpolymath commented on Aug 31, 2026

    @hyperpolymath
    hyperpolymath
    on Aug 31, 2026

    Additional user report on codex-cli 0.151.0 under WSL2/Windows Terminal: while editing a prompt, the user instinctively pressed Ctrl-X as the familiar clipboard cut shortcut. The TUI disappeared, and attempting to resume immediately failed with the exact active-writer error reported here.

    The usability impact is larger than an obscure key collision: Ctrl-X is a deeply learned clipboard/editing gesture, so binding a lone press to an immediate exit can unexpectedly disrupt a long conversation and make users reasonably fear that their thread has been lost.

    Please consider making Ctrl-X non-destructive by default, or requiring a confirmation/second press before exiting. If another writer remains active after an exit, the resume error should identify the owning process or surface and offer a safe attach/handoff/retry path. Configurable keymaps provide a local workaround, but users should not need to discover and remap a common clipboard shortcut after losing access to a session.

  12. brassdylan commented on Sep 3, 2026

    @brassdylan
    brassdylan
    on Sep 3, 2026 – with ChatGPT Codex Connector

    Additional macOS reproduction on Codex CLI 0.153.0 (Apple Silicon, running under tmux).

    This happened multiple times today while switching/resuming local TUI sessions. In the most recent case:

    1. Start a normal interactive Codex session and complete a turn.
    2. Press Ctrl-C twice in quick succession while exiting/interruption is in progress (habit from other terminal agents).
    3. The pane/session appears to exit.
    4. Try to resume the saved session with codex resume <thread-id>.
    5. Resume fails during TUI bootstrap with:
    thread/resume failed during TUI bootstrap:
thread/resume failed: thread <thread-id> already has an active writer (code -32600)

    The second Ctrl-C is another SIGINT, not SIGKILL, but it appears to expose a teardown race between the TUI, the Node wrapper, and the native Codex process. Local logs recorded repeated active-writer conflicts for the same thread across several minutes. The rollout remained present and ended with a normal completed turn; no rollout or database repair was needed.

    In this incident, stopping the abandoned Codex process/session eventually released the writer, and a clean resume then succeeded. The error did not identify the owning process or provide an attach, handoff, or safe recovery action. A separate thread showed the same error when an older TUI was still alive in another tmux pane, which made it difficult to distinguish “another active owner” from a stranded writer.

    Expected behavior:

    • repeated SIGINT during exit should leave the thread resumable;
    • if a live owner exists, identify the owning surface/process and offer attach or explicit handoff;
    • if the owner is gone, recover the writer automatically;
    • the error should not require users to inspect lsof and manually reason about process lifetimes.

    I have intentionally omitted usernames, repository paths, thread IDs, and raw transcripts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLITUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displayapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions