Repository navigation
[CLI][TUI][Linux] SSH disconnect leaves idle TUI holding the thread writer lock; resume fails with "already has an active writer" until the old process is killed #44063
Description
What version of Codex CLI is running?
codex-cli 0.153.4 (npm @openai/codex), reproduced 2026-09-09
What subscription do you have?
API-key authentication through a Responses-compatible provider; no ChatGPT subscription is involved in this reproduction.
Which model were you using?
deepseek-v4-flash
What platform is your computer?
Environment:
- Client: Windows Terminal (Windows 10, built-in OpenSSH ssh.exe), plain SSH session; no ServerAliveInterval configured on the client
- Host: Ubuntu 24.04.4 LTS (x86_64)
- codex-cli 0.153.4 installed via the @openai/codex npm package
- node v22.22.2 / npm 10.9.7
- Remote login shell: bash; no tmux/screen/zellij, no
sudo su, no VS Code
What terminal emulator and version are you using (if applicable)?
No response
Codex doctor report
What issue are you seeing?
If the SSH connection drops while the Codex TUI is running (even when it is
idle and the last turn is complete), the TUI process keeps running and keeps
holding the thread's writer lock. The server never notices the half-open TCP
connection (no ClientAliveInterval), so the process can survive for hours.
A later codex resume from a new SSH session fails with:
Error: Failed to resume session from ~/.codex/sessions//rollout-<...>-.jsonl:
thread/resume failed during TUI bootstrap: thread/resume failed:
thread already has an active writer (code -32600)
What steps can reproduce the bug?
- From Windows Terminal, run
ssh <user>@<host>andcdinto a project
directory on the remote host. - Run
codex, complete one turn, and leave the TUI idle at the prompt. - Abruptly kill the SSH client or drop the network.
- Reconnect and run
codex resume(or resume from the TUI picker). - Observe the "already has an active writer" failure.
What is the expected behavior?
No response
Additional information
This is the simplest possible repro of the "terminal disconnect leaves an
active writer" lifecycle problem: plain SSH, no editor integration, no wrapper
PTY chain. Configuring sshd ClientAliveInterval is only a server-side
workaround and does not help users who need to take over a thread from another
session while the stale process is still alive.
Related: #39345, #37403, #38297, #12515
Activity
github-actions commentedon Sep 9, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
murderteeth commentedon Sep 18, 2026
Also encountered this on Linux with
codex-cli 0.155.0while working over SSH.After an SSH disconnect and reconnect, attempting to continue the previous conversation showed:
Local inspection found that the previous Codex CLI process was still alive after roughly 22 hours and held the conversation's writer lock in
~/.codex/thread-writer-locks/. Its saved rollout ended with a completed turn; it was idle. Sending SIGTERM to that specific process released the lock, without deleting the saved conversation or interrupting the separate current Codex session.Please provide a built-in recovery action directly on this screen, such as “Take over and resume”, or an equivalent CLI recovery command. It should identify the existing owner, let the user explicitly end/release that owner's session, and acquire the writer lock before continuing the same conversation. If a turn is still active, make that clear before takeover.
The requested behavior preserves the single-writer guarantee; simply deleting the lock file while its owner is alive is not a safe substitute. Reconnecting after a dropped SSH connection should not require manually matching lock files to PIDs, maintaining a custom recovery script, or adopting tmux just to continue a saved conversation.