fix: support Windows clipboard in remote HTTP terminals - #875
Draft
wesm wants to merge 4 commits into
Draft
Conversation
Chrome users opening Forge over an HTTP Tailscale address could not reliably paste Windows clipboard text into a tmux workspace. Forge handled multiline paste itself but delegated the common single-line case to xterm, leaving two browser input paths with different behavior. Make Forge own every non-empty text paste event, preserve the existing sanitizer and bracketed-paste mode, and stop xterm from sending the same event again. A real Chromium test now proves that the shortcut sends one payload through the terminal WebSocket and reaches tmux. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
Chrome treats loopback as a secure context, so the prior regression could pass through xterm's Clipboard API path and miss the reported Tailscale HTTP failure. Run the terminal through a non-loopback HTTP and WebSocket proxy. Exercise the cancelable browser paste-event boundary because headless Linux keyboard injection does not issue the native browser paste command. Verify Forge stops xterm's later handler and tmux receives one payload. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
Member
Author
|
Addressed in This intentionally starts at the |
roborev: Combined Review (
|
Member
Author
|
tested and not working yet, so will keep at this |
mariusvniekerk
marked this pull request as draft
August 10, 2026 20:42
Chrome users who open Forge through a plain-HTTP Tailscale address still need normal terminal clipboard behavior. xterm consumed paste shortcuts before Chrome could create a paste event, and remote clients could not use the local-server clipboard fallback when the secure Clipboard API was unavailable. Keep native paste shortcuts browser-owned, provide a gesture-authorized copy-event fallback, and reserve insecure-origin right click for Chrome's context menu. The insecure-origin regression now exercises real clipboard paste and copy through tmux. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
wesm
changed the title
roborev: Combined Review (
|
The pane-move regression denied only the async Clipboard API. The new synchronous browser-copy path therefore succeeded before the test could observe its intended server fallback, which made the full E2E job fail after the product fix. Deny both browser clipboard paths and stop coupling tmux command entry to exact terminal rendering bytes. The test still proves that keyboard focus survives the move and that OSC 52 reaches the forced fallback. Generated with Codex Co-authored-by: Codex <noreply@openai.com>
roborev: Combined Review (
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Chrome users who open Forge through a plain-HTTP remote deployment could not reliably paste Windows clipboard text into a tmux workspace. xterm consumed Ctrl-V and Ctrl-Shift-V before Chrome could create a paste event. Copying from tmux also failed because the secure Clipboard API is unavailable on these origins, while Forge's server fallback is intentionally local-client-only.
Forge now leaves native paste shortcuts to the browser and consumes each resulting terminal paste event exactly once. Gesture-authorized terminal copy falls back to the browser's copy event when the modern Clipboard API is unavailable. On insecure origins, right-button mouse events stay out of tmux so Chrome's native context menu remains usable for paste.
The regression serves Forge through a non-loopback HTTP and WebSocket proxy, confirms the page is an insecure context without the async Clipboard API, and uses the real OS clipboard with trusted paste shortcuts. It verifies exact-once tmux input, tmux copy back to the OS clipboard, and no tmux mouse input from right click. The pinned Linux Chromium run exercises Ctrl-V and Ctrl-Shift-V directly.
Validation