TUI leaves terminal in raw/corrupted state on /exit under Alacritty + zellij-windows (Windows ConPTY)

[kraso]

Description

OpenCode CLI's TUI intermittently leaves the terminal in a corrupted state when exiting via /exit while running inside Alacritty + Zellij on Windows. No response/confirmation is needed from the maintainers below — this is a bug report.

Environment

• OS: Windows 11 (10.0.26200)
• Terminal: Alacritty 0.17.0
• Multiplexer: arndawg.zellij-windows 0.43.1-win32.5 (community fork; zellij has no official Windows support)
• OpenCode version: 1.18.30
• Shell in pane: PowerShell / pwsh

Expected behavior

Exiting via /exit closes OpenCode cleanly and returns to the pane's shell, leaving the Zellij pane usable (and showing the session-reminder message so the session can be resumed). This occasionally happens — the correct behavior — but the result is unpredictable across runs.

Actual (erratic) behavior

Three different outcomes occur non-deterministically:

1. Pane closes too: exiting via /exit sometimes also drops the whole Zellij pane.
2. Clean exit: only OpenCode closes; the pane stays alive and usable (expected).
3. Corrupted terminal state: before any exit, the app freezes and a series of strange characters appears at the bottom of the pane "as if the terminal were available when it is not". Pressing keys or moving the mouse then emits further gibberish — a mix of special characters, numbers and closing brackets (typical of leaked raw-mode sequences, e.g. raw mouse-report sequences like ESC[<...M).

Root-cause hypothesis

The TUI renderer is acquired with Effect.acquireRelease(...) and calls destroyRenderer() on release, which exits the alternate screen buffer and restores cooked terminal mode (see packages/tui/src/app.tsx). If that cleanup is bypassed — process.exit(), SIGKILL, or the renderer release being interrupted when the multiplexer tears down the PTY — the terminal remains in raw mode on the alternate screen. Under Windows ConPTY with a second Pty layer (the zellij-windows fork), the mode reset is not propagated to the outer terminal when the process dies uncleanly, so subsequent input/output prints uninterpreted escape sequences.

Mouse reporting is enabled by default (useMouse), which accounts for the numeric/bracket garbage once the terminal state has leaked.

Steps to reproduce

1. Launch Alacritty.
2. Start zellij (0.43.1-win32.5).
3. In a pane, run opencode.
4. Use the TUI normally, then exit via /exit.
5. Repeat several times (also try closing the pane while OpenCode is running).

Observe the three outcomes above. Once in the corrupted state, any keypress/mouse move prints additional raw escape sequences until the pane is force-closed.

Suggested areas to investigate

• Guarantee destroyRenderer() runs on every exit path (clean /exit, Ctrl+C, process exit, and external PTY close).
• Consider a fallback (e.g. atexit/signal handler) that force-resets the terminal (\x1b[0m, leave alternate screen, disable mouse reporting, restore cooked mode) even on abnormal termination.
• Test under a single ConPTY layer (plain Alacritty tab, no zellij) to confirm the multi-Pty ConPTY interaction.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• After closing the OpenCode CLI, scrolling the mouse wheel and moving the mouse in the powershell will cause garbled characters. #11748: Mouse movement causes garbled characters in PowerShell after closing OpenCode CLI (same leaked mouse-reporting sequences)
• [Windows] Terminal left with raw ANSI escape codes after crash (PowerShell) #21277: Terminal left with raw ANSI escape codes after crash on Windows/PowerShell (same root cause — missing terminal reset on unclean exit)
• WSL2 Ubuntu-26.04 terminal crashes after /exit #30133: WSL2 terminal crashes after /exit, starts mouse tracking / garbled keyboard (same symptom set)
• Running in RMUX: terminal unresponsive after /exit #38068: Terminal unresponsive after /exit when running inside a multiplexer (rmux) on Windows native
• TUI not responding and mapping mouse as keyboard in the console #46216: TUI not responding and mapping mouse as keyboard in the console (same raw mouse-report leakage on Windows)

[kraso]

Thanks for flagging the related issues. Confirming the duplicates noted, and consolidating the evidence here since the fix affects all of them.

Related issue family (all OPEN, no fix landed yet):

• After closing the OpenCode CLI, scrolling the mouse wheel and moving the mouse in the powershell will cause garbled characters. #11748 — garbled chars on mouse move after closing the TUI (oldest, Windows/PowerShell)
• [Windows] Terminal left with raw ANSI escape codes after crash (PowerShell) #21277 — raw ANSI escape codes left in terminal after crash (Windows/PowerShell)
• WSL2 Ubuntu-26.04 terminal crashes after /exit #30133 — WSL2 terminal crash after /exit
• Running in RMUX: terminal unresponsive after /exit #38068 — terminal unresponsive after /exit inside a multiplexer (rmux)
• TUI not responding and mapping mouse as keyboard in the console #46216 — TUI mapping mouse as keyboard in console
• macOS: exit/cleanup path broadcasts SIGTERM to ALL user processes (kill -1) — kills Ghostty, Terminal, Chrome, entire session (1.18.24 & 1.18.25) #45938 — macOS: exit cleanup broadcasts SIGTERM (kill -1) to ALL user processes, killing the whole session including the terminal

What this issue adds (canonical Windows reproduction):

• Alacritty 0.17.0 + zellij-windows fork (0.43.1-win32.5), opencode 1.18.30
• Video: pane takes down the entire Zellij session on /exit
• The non-deterministic outcomes: whole session closes / clean exit / leaked alternate-screen + raw-mode corruption (stray chars, mouse-report sequences)
• Cross-links the macOS kill -1 bug (macOS: exit/cleanup path broadcasts SIGTERM to ALL user processes (kill -1) — kills Ghostty, Terminal, Chrome, entire session (1.18.24 & 1.18.25) #45938), which is likely the same shutdown-cleanup flaw: the renderer's destroyRenderer() state restore is bypassed on unclean exit, so raw mode/altscreen/mouse-tracking are never reset on the PTY

Happy to close this as a duplicate in favor of whichever canonical issue the maintainers prefer — the video and Windows repro can be attached to that one instead.