Summary
On a remote SSH worktree, Supacode's Beta terminal surface corrupts the displayed command line under burst input. Extra characters and displaced fragments appear in the rendered line, but the remote shell executes a shorter, correct input. The same session does not corrupt input when driven through macOS Terminal.app.
This makes the Supacode surface effectively unusable for normal typing.
Environment
- Supacode
0.10.6 (build 1783877721)
- macOS
26.5.2 (25F84), Apple Silicon
- Remote host: Ubuntu, login shell
zsh, connected through Supacode SSH remote worktree support
- Supacode bundled
zmx 0.6.0, reporting ghostty_vt ghostty-1.3.2-dev-5UdBC8HuDgWFQtz8pKQ-0HH6z0Cb_PKbI0R7AunQhdDF
Reproduction
- Open a remote SSH repository in Supacode.
- Focus its Beta terminal surface.
- Type a sequence quickly enough to generate burst input.
- Press Return.
Actual result
The displayed command line contained extra/displaced text, including:
qsdazeqsdqqssd azzzzzzzzzzqdqsdxwcqsdqsd
The shell actually executed only:
and returned:
qsdazeqsd: command not found
A later burst showed the same divergence even more clearly: the renderer interleaved repeated qsd fragments between characters, while the shell executed only the non-interleaved prefix.
Control test
I attached a second client to the exact same live Supacode session through the bundled zmx, first from a separate PTY and then from macOS Terminal.app.
- Eight back-to-back ~80-character commands sent through the separate PTY all echoed and executed exactly.
- macOS Terminal.app sent:
printf 'TERMINALAPP_BURST_ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_OK\n'
and received exactly:
TERMINALAPP_BURST_ABCDEFGHIJKLMNOPQRSTUVWXYZ_0123456789_abcdefghijklmnopqrstuvwxyz_OK
No extra characters appeared in either control path.
Expected result
The Supacode surface should render exactly the bytes accepted by the remote shell, including during burst input.
Interpretation
The echoed-vs-executed divergence and same-session Terminal.app control strongly isolate this to Supacode's embedded Ghostty-backed terminal/rendering path rather than the keyboard, SSH transport, remote shell, or remote host.
Workaround
Attaching via zmx from another terminal is usable. Remote-side zmx also provides disconnect survival once it is visible on the login shell's PATH.
Summary
On a remote SSH worktree, Supacode's Beta terminal surface corrupts the displayed command line under burst input. Extra characters and displaced fragments appear in the rendered line, but the remote shell executes a shorter, correct input. The same session does not corrupt input when driven through macOS Terminal.app.
This makes the Supacode surface effectively unusable for normal typing.
Environment
0.10.6(build1783877721)26.5.2(25F84), Apple Siliconzsh, connected through Supacode SSH remote worktree supportzmx 0.6.0, reportingghostty_vt ghostty-1.3.2-dev-5UdBC8HuDgWFQtz8pKQ-0HH6z0Cb_PKbI0R7AunQhdDFReproduction
Actual result
The displayed command line contained extra/displaced text, including:
The shell actually executed only:
and returned:
A later burst showed the same divergence even more clearly: the renderer interleaved repeated
qsdfragments between characters, while the shell executed only the non-interleaved prefix.Control test
I attached a second client to the exact same live Supacode session through the bundled
zmx, first from a separate PTY and then from macOS Terminal.app.and received exactly:
No extra characters appeared in either control path.
Expected result
The Supacode surface should render exactly the bytes accepted by the remote shell, including during burst input.
Interpretation
The echoed-vs-executed divergence and same-session Terminal.app control strongly isolate this to Supacode's embedded Ghostty-backed terminal/rendering path rather than the keyboard, SSH transport, remote shell, or remote host.
Workaround
Attaching via
zmxfrom another terminal is usable. Remote-sidezmxalso provides disconnect survival once it is visible on the login shell'sPATH.