Zellij switch-away leaves Codex TUI on a stale viewport while the turn completes in the rollout

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

What version of Codex CLI is running?

codex-cli 0.146.0 (the latest stable version reported by the built-in update check at the time of the incident)

What subscription do you have?

ChatGPT Pro ($200/month, 20x limits)

Which model were you using?

gpt-5.6-sol, reasoning effort xhigh

What platform is your computer?

Host: Windows 10 Enterprise 22H2, build 19045.6456
Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 x86_64
Ubuntu 22.04.5 LTS under WSL2

What terminal emulator and version are you using (if applicable)?

Windows Terminal 1.24.11911.0 → WSL2 → Zellij 0.44.3

Zellij binary: /usr/local/bin/zellij. zellij setup --check reports that the active config is well defined.

Codex doctor report

The following is a manually reduced, public-safe subset of codex doctor --json. The full output contains local filesystem paths and unrelated historical thread records, so it has not been included in this review draft.

{
  "schemaVersion": 1,
  "overallStatus": "warning",
  "codexVersion": "0.146.0",
  "relevantChecks": {
    "config.load": {
      "status": "ok",
      "model": "gpt-5.6-sol"
    },
    "installation": {
      "status": "ok",
      "installMethod": "npm",
      "platform": "linux-x86_64"
    },
    "network.websocket_reachability": {
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded"
    },
    "terminal.env": {
      "status": "ok",
      "terminal": "Windows Terminal",
      "multiplexer": "zellij 0.44.3"
    },
    "updates.status": {
      "status": "ok",
      "latestVersion": "0.146.0",
      "currentVersionIsLatest": true
    }
  },
  "redactionNote": "Local paths and unrelated historical thread records omitted. The overall warning came from unrelated stale archived-thread database rows."
}

What issue are you seeing?

In a long-running local Codex TUI inside Zellij, I submitted a new prompt and saw the UI enter Working. After switching away from the affected Zellij view and returning, Codex displayed an older point in the conversation instead of the latest turn. The newly submitted user message and its result were both absent from the visible TUI.

This appeared to be data loss, but inspection of the local rollout JSONL showed that the user message was persisted and the turn continued through task_complete. The issue therefore appears to be a stale TUI viewport or replay/reconciliation problem rather than loss of the underlying conversation.

Detaching and reattaching to the same Zellij session did not repair the display. Zellij's scroll-to-bottom action also did not reveal the missing turn. The same older screen was restored.

There was no visible error message. The Codex process remained alive.

What steps can reproduce the bug?

I have one confirmed incident, not yet a minimal deterministic reproduction.

  1. Start Codex CLI normally inside a Zellij session. Do not use --remote.
  2. Continue using the same Codex and Zellij session for a long period with a sizable transcript.
  3. Submit a new prompt and observe the Codex status change to Working.
  4. Switch away from the affected Zellij tab/pane/session while the turn is active, then return.
  5. Observe that the TUI is showing an older point in the conversation. The latest user prompt and subsequent assistant result are not visible.
  6. Detach with Ctrl+o, d, then reattach with zellij attach -c <session>.
  7. Observe that the same stale viewport is restored. Scrolling to the bottom does not expose the latest turn.
  8. Inspect the rollout JSONL separately. The missing prompt and the completed turn are present there.

Thread ID: intentionally omitted from the public draft. I can provide it privately or add it after reviewing the privacy implications.

What is the expected behavior?

Returning to the Zellij view, or detaching and reattaching, should redraw Codex at the current conversation state. At minimum, scrolling to the bottom should reveal the latest submitted prompt, live progress, and final response.

The visible TUI should not remain on an older snapshot when the authoritative rollout has already persisted and completed a newer turn.

Additional information

  • Codex was running locally; this was not a codex --remote connection.
  • The Windows host was Windows 10 Enterprise 22H2, build 19045.6456, using Windows Terminal 1.24.11911.0. I have not yet reproduced the exact incident under a second terminal emulator, so Windows Terminal/ConPTY cannot be completely excluded as a trigger.
  • I have also observed the same stale/missing-current-turn symptom on a separate home computer running Windows 11 + Windows Terminal + WSL2 + Zellij. Exact Codex, Zellij, WSL, and Windows Terminal versions were not captured for that occurrence. This makes a Windows 10-specific cause unlikely, but Windows Terminal remains a common variable. This is supporting observation rather than a controlled reproduction.
  • No tui.alternate_screen override is set. The effective documented default is auto, which skips alternate-screen mode in Zellij to preserve scrollback.
  • The affected Zellij session was approximately 25 hours old.
  • The affected pane had approximately 4,372 scrollback lines, and the rollout file was approximately 1.7 MB.
  • A normal-output control pane in Zellij retained hundreds of lines correctly, so Zellij's basic scrollback storage was functioning.
  • Zellij's own dump-screen --full output also ended at the stale Codex view and did not contain the latest persisted turn. This makes a Windows Terminal rendering-only failure unlikely, although it does not rule out a terminal focus/resize event as the trigger.
  • Zellij scroll-to-bottom did not change the stale Codex view.
  • Sending a terminal resize signal did not visibly redraw the current conversation.

Persisted event metadata for the missing turn (2026-08-04 UTC; message contents omitted):

| Time | Persisted event |
| --- | --- |
| 08:47:58.788 | task_started |
| 08:47:58.831 | user message persisted |
| 08:48:08.232 | assistant commentary persisted |
| 08:48:16.045 | tool call completed |
| 08:48:20.509 | tool result persisted |
| 08:48:32.509 | final assistant message persisted |
| 08:48:33.006 | task_complete |

Potentially related issues, but none appears to cover this exact local-CLI failure mode:

I am not asserting a root cause. The combination of a completed rollout, an alive Codex process, functioning ordinary Zellij scrollback, and a viewport that survives detach/reattach suggests a Codex TUI render/replay/reconciliation issue.

The related Zellij/scrollback class is not Windows-specific: #2558 was reported on macOS, and #10331 was reported on native Linux with Ghostty. Those reports are not the same missing-current-turn symptom, so they do not prove that this exact incident is cross-platform. However, my separate Windows 11 + WSL2 + Zellij observation does indicate that the exact symptom is not limited to this Windows 10 host.

Raw transcript and terminal captures are not attached because they contain user prompts, local paths, and a signed CDN URL. I can provide narrowly redacted artifacts if maintainers identify the specific metadata needed.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 24 days ago

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

  • #36338

Powered by Codex Action

whikqp · 24 days ago

Thanks — #36338 is very close and may share the same underlying TUI/Zellij lifecycle bug.

One important distinction is the observed trigger. In this incident, the Codex view was already stale before detaching. Detach/reattach was attempted as a recovery step and restored the same stale view; it was not the known initial trigger. The latest prompt had entered Working, then disappeared from the visible TUI after switching away and back, while the local rollout persisted the user message and continued through task_complete.

Additional evidence:

  • Zellij dump-screen --full captured the same stale/old Codex view, making a Windows Terminal rendering-only failure unlikely.
  • The Codex process remained alive, and SIGWINCH did not restore the current view.
  • The same stale/missing-current-turn symptom was also observed on a separate Windows 11 + Windows Terminal + WSL2 + Zellij machine, although exact versions were not captured there.
  • #36338 reproducing on Arch Linux + Kitty also suggests that Windows/WSL is not required for the broader failure mode.

I am happy to consolidate this into #36338 if maintainers determine that both reports have the same root cause. The rollout evidence here may still be useful because it confirms that the authoritative turn completed while the visible TUI remained stale.