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

[whikqp]

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:

• #2558 — Codex client output truncated when scrolling in Zellij concerns truncated scrollback.
• #10331 — Zellij scrollback still broken with --no-alt-screen concerns full-screen redraw in the main buffer.
• #18860 — Remote TUI can remain stale after app-server slow-websocket disconnect is similar in symptom, but it concerns a remote app-server connection; this incident used the local CLI.
• #15001 — Subagent TUI corrupts live message text while raw rollout is correct also has a correct raw rollout, but this incident occurred in the primary local TUI rather than a subagent view.

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.

[github-actions]

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

• Codex TUI freezes after Zellij detach/reattach; suspending before detach avoids it #36338

Powered by Codex Action

[whikqp]

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.
• Codex TUI freezes after Zellij detach/reattach; suspending before detach avoids it #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.