›_ Codex Issues
Codex Issues / #29730

Ctrl-Z suspend during active work can leave shell unusable after resume over tsh/Slurm

Open 💬 5 comments Opened Jun 23, 2026 by mvillmow
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

When Codex is doing work and I press Ctrl+Z to suspend it, then resume it, the shell can be left in a broken state where I cannot submit any commands.

Environment

  • Local terminal: iTerm2 on macOS
  • Remote access: tsh into a Linux Slurm cluster
  • Workload context: Codex running active work on cluster/login nodes

Reproduction

  1. Open iTerm2 on macOS.
  2. Connect to a Linux Slurm cluster using tsh.
  3. Start Codex and let it begin active work.
  4. Press Ctrl+Z to suspend Codex.
  5. Bring Codex back with fg.
  6. Try to enter and submit shell commands.

Expected behavior

After resume, Codex and/or the shell should restore terminal state cleanly. The shell should accept and submit commands normally.

Actual behavior

After Codex comes back up, the shell does not work properly and commands cannot be submitted.

Notes

This looks like it may involve terminal mode or job-control state not being restored correctly after SIGTSTP/SIGCONT, especially through iTerm2 plus tsh on remote Linux machines.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29718

Powered by Codex Action

aroman · 1 month ago

Getting this too, 0.144.1 on Linux.

johnaweiss · 27 days ago

in my experience with codex CLI on WSL Linux, it drops out of codex back to command line. I just lost of ton of work as a result. Why can't open ai give us a decent CLI editor?

VanTanev · 22 days ago
Clarification (2026-08-05): the reporter's exact sequence is Ctrl-Z followed by bg, not Ctrl-Z followed later by fg. That is a distinct background-job/foreground-terminal-ownership bug and is now tracked separately in #37088. The source analysis below is related, but this comment should not be treated as an exact reproduction of #29730.

Additional current Linux/tmux reproduction, with a likely regression/source-level cause.

Environment

  • Codex CLI: 0.146.0 (standalone x86_64-unknown-linux-musl)
  • Linux
  • zsh
  • tmux 3.6
  • TERM=tmux-256color, TERM_PROGRAM=tmux
  • codex doctor --summary: 17 ok, 0 warn, 0 fail

Symptom

After suspending the interactive TUI with Ctrl-Z and returning to the shell, ordinary command output can render as a staircase because each LF starts at the previous output column instead of column zero:

## branch
         M file-one
                   ?? file-two

That byte/display pattern is characteristic of output post-processing/newline translation being left disabled (OPOST / ONLCR). stty sane recovers the terminal.

Relevant source

The previously closed #26564 contains a traced Linux root cause and a tested one-line fix: the TUI runs on a spawned codex-main thread, but the suspend path uses process-group-directed kill(0, SIGTSTP). Signal delivery can race onto another thread, allowing the TUI thread to reapply raw terminal modes before the job is actually stopped. The reported fix changes that call to thread-directed raise(SIGTSTP) and checks its return value:

https://github.com/kamou/codex/commit/e09ac2f76004ae061d9c99bfce6f87e7072f5dcc

However, both the rust-v0.146.0 tag and current main still contain kill(0, SIGTSTP) in codex-rs/tui/src/tui/job_control.rs:

This looks like the #26564 fix was never incorporated, or the problematic implementation was restored later. Could the suspend path use libc::raise(SIGTSTP) as in the validated patch and add a PTY/job-control regression test that asserts canonical mode, echo, OPOST, and ONLCR are restored before the shell regains control?

glevco · 9 days ago

Additional reproduction on Codex CLI 0.147.0 (aarch64-unknown-linux-musl):

  • Codex runs on a Linux VM over direct SSH from macOS.
  • Ctrl+Z followed by fg corrupts the resumed TUI.
  • Reproduces from Ghostty, Terminal.app, and iTerm.
  • Reproduces outside Herdr and with both TERM=xterm-ghostty and TERM=xterm-256color.
  • Local macOS does not reproduce.
  • Foreground process-group ownership is correct.
  • Startup diagnostics report cursor_position=true and keyboard_enhancement_supported=Some(true).
  • Every observed resume logs terminal cursor position unavailable after resume, followed by restored terminal state after resume event="tui_suspend_resumed"; no tui_suspend_failed event is recorded.

Diagnostic feedback was uploaded as thread 01a015a9-1ece-7720-8f66-0da92d448c91.