PR #9199 — Android test
Verdict: request changes
The clipboard workflow works on the physical device, but an asynchronous route-switch race can write the clipboard into a terminal that is no longer selected.
Physical preview-build pass
- PASS Existing T3 Connect session resumed and its saved environment synced.
- PASS Existing thread terminal opened without sending an agent message.
- PASS The keyboard accessory exposes the new
pasteaction. - PASS Paste button inserted
PR9199_LINE1\nPR9199_LINE2; the newline became a terminal carriage return. - PASS Cmd+V used the Android clipboard on the detected macOS host.
- PASS Toggling Ctrl off disarmed it; the following
zwas literal input. - PASS No fatal Android exception, unhandled JS exception, or clipboard-read error appeared in logcat.
Evidence
Findings
BLOCKERPaste can target a stale terminal after navigation
pasteFromClipboard awaits the native clipboard and then calls the captured writeInput. If the route, thread, environment, or terminal changes during that await, the old callback still writes to the old PTY. The web terminal already guards its async paste with a current-token check.
MEDIUMHost OS is inferred from a display label
Label matching decides whether paste is Cmd+V or Ctrl+V. Neutral Mac labels can get Ctrl+V, while unrelated text containing “win” can be classified as Windows. The server config exposes the actual host OS.
LIMITClipboard payload is not chunked
The encoder forwards the entire value through one terminal write, while the wire contract caps terminal input at 65,536 characters. Longer clipboard contents fail instead of being split or rejected locally.
Automated verification
- New terminal-input tests: 10/10 passed.
- Mobile terminal tests: 44/44 passed.
- Mobile typecheck, targeted lint/format, and Android debug build passed.
- GitHub CI is green on
87d3aa4.
Scope note
The test used deliberately invalid shell text so it only produced “unknown command” output. No agent message was sent, and no pairing or environment replacement was performed.