Hi,
I ran into a really confusing issue where resuming an old OpenCode session made the TUI basically unusable — arrow keys, delete, and shortcuts stopped working, and the screen kept getting cleared/redrawn in weird ways.
The problem in one sentence: pty_read results and <pty_exited> notifications write raw PTY output (including ANSI/VT escape sequences) directly into the OpenCode session, and the TUI re-executes those sequences every time it renders the message.
Real impact
- Sessions that output terminal-mode sequences like
ESC[?9001h, ESC[?1004h, ESC[?25l, ESC[2J, or ESC]0;... permanently poison the chat history.
- Every time you open, resume, or fork the session, the TUI re-runs the sequences. In my case this meant the screen was cleared and the keyboard input mode was switched, so arrow keys / delete / shortcuts stopped working (typing via the IME still worked, which made it extra confusing).
- New sessions and unrelated sessions are fine; only the poisoned session is affected. Forking copies the bad messages, so the fork is also broken.
Reproduction
The simplest repro is to spawn anything that prints a terminal-mode sequence and then read or resume the session:
pty_spawn: command="printf", args=["\x1b[?9001h\x1b[?25ldone\n"], description="ansi repro"
pty_read: id=<pty-id>
After the pty_read returns, close and reopen the session. The TUI will re-execute ESC[?9001h and ESC[?25l when it renders that message.
A more realistic trigger is running a Playwright test suite or anything that uses a TTY-aware tool under a pseudo-terminal — the PTY gets the raw sequences, and they end up in opencode.db unchanged.
Environment
- Windows 11 + Windows Terminal
- opencode 1.18.34
- opencode-pty 0.4.0
Workaround
I confirmed the cause by finding parts in opencode.db that contain \u001b and replacing the escape byte with visible text:
sqlite3 ~/.local/share/opencode/opencode.db "UPDATE part SET data = replace(data, '\u001b', '[ESC]') WHERE data LIKE '%\u001b%';"
After that, the affected session resumed normally.
Suggested fix
Sanitize ANSI/VT escape sequences (CSI, OSC, and stray ESC) before writing PTY output into pty_read results or <pty_exited> notifications. The raw buffer can stay untouched so the Web UI / xterm.js stream still works. A config option (e.g. PTY_SANITIZE_OUTPUT=false) to keep raw output would be nice for debugging.
Hi,
I ran into a really confusing issue where resuming an old OpenCode session made the TUI basically unusable — arrow keys, delete, and shortcuts stopped working, and the screen kept getting cleared/redrawn in weird ways.
The problem in one sentence:
pty_readresults and<pty_exited>notifications write raw PTY output (including ANSI/VT escape sequences) directly into the OpenCode session, and the TUI re-executes those sequences every time it renders the message.Real impact
ESC[?9001h,ESC[?1004h,ESC[?25l,ESC[2J, orESC]0;...permanently poison the chat history.Reproduction
The simplest repro is to spawn anything that prints a terminal-mode sequence and then read or resume the session:
After the
pty_readreturns, close and reopen the session. The TUI will re-executeESC[?9001handESC[?25lwhen it renders that message.A more realistic trigger is running a Playwright test suite or anything that uses a TTY-aware tool under a pseudo-terminal — the PTY gets the raw sequences, and they end up in
opencode.dbunchanged.Environment
Workaround
I confirmed the cause by finding parts in
opencode.dbthat contain\u001band replacing the escape byte with visible text:After that, the affected session resumed normally.
Suggested fix
Sanitize ANSI/VT escape sequences (CSI, OSC, and stray
ESC) before writing PTY output intopty_readresults or<pty_exited>notifications. The raw buffer can stay untouched so the Web UI / xterm.js stream still works. A config option (e.g.PTY_SANITIZE_OUTPUT=false) to keep raw output would be nice for debugging.