anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

OSC52 clipboard doesn't work with VS Code Remote SSH - need fallback or detection #8400

New Issue
Closed
opened 2026-02-16 18:09:52 -05:00 by yindo · 8 comments
yindo commented 2026-02-16 18:09:52 -05:00
Owner
Copy Link
Copy Source

Originally created by @ErcinDedeoglu on GitHub (Feb 3, 2026).

Originally assigned to: @kommander on GitHub.

Problem

v1.1.49 (released today, Feb 3, 2026) introduced OSC52 clipboard via "Use OpenTUI OSC52 clipboard implementation". This does not work with VS Code Remote SSH - one of the most popular remote development setups.

This is a regression - clipboard operations that may have worked before (or at least didn't claim success) now show a success message but silently fail.

VS Code Remote SSH has a known limitation where OSC52 escape sequences are not properly forwarded to the local terminal. This has been documented for years:

Current Behavior (v1.1.49)

  1. User runs opencode via VS Code Remote SSH
  2. User copies something (Ctrl+X Y, copy last message, etc.)
  3. opencode shows "Copied to clipboard" toast ✓
  4. Nothing is actually in the clipboard ✗

This is misleading - users think it worked when it didn't.

Environment Detection

The issue is detectable. VS Code Remote SSH sessions have:

TERM_PROGRAM=vscode
VSCODE_IPC_HOOK_CLI=/tmp/vscode-ipc-xxx.sock

Combined with no DISPLAY and XDG_SESSION_TYPE=tty, this indicates VS Code Remote SSH where OSC52 won't work.

Suggested Solutions

Option 1: Detect and Warn

When detecting VS Code Remote SSH environment, show a warning:

"Clipboard via OSC52 may not work in VS Code Remote SSH. Use mouse selection + Cmd+C instead."

Option 2: VS Code Extension Integration

VS Code extensions can access the local clipboard. Consider:

  • A companion VS Code extension that opencode can communicate with
  • Using VS Code's clipboard API via the extension host

Option 3: Better Error Handling

PR #8974 fires OSC52 "first, always" but has no way to verify it worked. At minimum:

  • Don't show "Copied to clipboard" if we can't verify success
  • Show "Attempted to copy (OSC52)" with a note about potential limitations

Option 4: Alternative Clipboard Methods

For VS Code Remote SSH specifically:

  • Write to a temp file that user can manually copy
  • Integrate with VS Code's terminal selection (select text programmatically)

Impact

VS Code Remote SSH is extremely popular for remote development. Many users are affected by this silent failure introduced in v1.1.49. The current behavior where opencode claims success but nothing is copied is frustrating and breaks trust.

Related

  • PR #8974 - Added OSC52 support (merged Jan 16, 2026)
  • v1.1.49 changelog - "Use OpenTUI OSC52 clipboard implementation" (released Feb 3, 2026)
  • PR #9008 - Open PR for "improve OSC 52 escape sequence for SSH compatibility"
  • Issue #2773 - Original clipboard issue

Request

Please either:

  1. Detect VS Code Remote SSH and warn users, OR
  2. Provide an alternative clipboard method for this environment, OR
  3. Don't claim success when we can't verify the clipboard operation worked

The current silent failure with a misleading success message is the worst possible UX. This is especially urgent since it just shipped today and will affect many users upgrading to v1.1.49.

Originally created by @ErcinDedeoglu on GitHub (Feb 3, 2026). Originally assigned to: @kommander on GitHub. ## Problem v1.1.49 (released **today**, Feb 3, 2026) introduced OSC52 clipboard via "Use OpenTUI OSC52 clipboard implementation". This **does not work** with VS Code Remote SSH - one of the most popular remote development setups. **This is a regression** - clipboard operations that may have worked before (or at least didn't claim success) now show a success message but silently fail. VS Code Remote SSH has a **known limitation** where OSC52 escape sequences are not properly forwarded to the local terminal. This has been documented for years: - [vscode-remote-release #5905](https://github.com/microsoft/vscode-remote-release/issues/5905) - "Backlog Candidates" since 2021 - [vscode-remote-release #8049](https://github.com/microsoft/vscode-remote-release/issues/8049) - "Backlog" since 2023 - [GitHub Community #153471](https://github.com/orgs/community/discussions/153471) - Same issue in Codespaces ## Current Behavior (v1.1.49) 1. User runs opencode via VS Code Remote SSH 2. User copies something (Ctrl+X Y, copy last message, etc.) 3. opencode shows **"Copied to clipboard"** toast ✓ 4. **Nothing is actually in the clipboard** ✗ This is misleading - users think it worked when it didn't. ## Environment Detection The issue is detectable. VS Code Remote SSH sessions have: ``` TERM_PROGRAM=vscode VSCODE_IPC_HOOK_CLI=/tmp/vscode-ipc-xxx.sock ``` Combined with no `DISPLAY` and `XDG_SESSION_TYPE=tty`, this indicates VS Code Remote SSH where OSC52 won't work. ## Suggested Solutions ### Option 1: Detect and Warn When detecting VS Code Remote SSH environment, show a warning: > "Clipboard via OSC52 may not work in VS Code Remote SSH. Use mouse selection + Cmd+C instead." ### Option 2: VS Code Extension Integration VS Code extensions can access the local clipboard. Consider: - A companion VS Code extension that opencode can communicate with - Using VS Code's clipboard API via the extension host ### Option 3: Better Error Handling PR #8974 fires OSC52 "first, always" but has no way to verify it worked. At minimum: - Don't show "Copied to clipboard" if we can't verify success - Show "Attempted to copy (OSC52)" with a note about potential limitations ### Option 4: Alternative Clipboard Methods For VS Code Remote SSH specifically: - Write to a temp file that user can manually copy - Integrate with VS Code's terminal selection (select text programmatically) ## Impact VS Code Remote SSH is extremely popular for remote development. Many users are affected by this silent failure introduced in v1.1.49. The current behavior where opencode claims success but nothing is copied is frustrating and breaks trust. ## Related - PR #8974 - Added OSC52 support (merged Jan 16, 2026) - v1.1.49 changelog - "Use OpenTUI OSC52 clipboard implementation" (released Feb 3, 2026) - PR #9008 - Open PR for "improve OSC 52 escape sequence for SSH compatibility" - Issue #2773 - Original clipboard issue ## Request Please either: 1. **Detect** VS Code Remote SSH and warn users, OR 2. **Provide** an alternative clipboard method for this environment, OR 3. **Don't claim success** when we can't verify the clipboard operation worked The current silent failure with a misleading success message is the worst possible UX. This is especially urgent since it just shipped today and will affect many users upgrading to v1.1.49.
yindo added the opentui label 2026-02-16 18:09:52 -05:00
yindo closed this issue 2026-02-16 18:09:52 -05:00
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 3, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #11904: Copy function broken in Windows 11 Terminal and Warp - also reports copy functionality failures similar to the OSC52 issues described here

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Feb 3, 2026): This issue might be a duplicate of existing issues. Please check: - #11904: Copy function broken in Windows 11 Terminal and Warp - also reports copy functionality failures similar to the OSC52 issues described here Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@ErcinDedeoglu commented on GitHub (Feb 3, 2026):

Update: Mouse selection workaround also broken

The situation is actually worse than described. Mouse text selection doesn't work as a workaround because:

  1. User tries to select text with mouse
  2. On mouse button release, opencode intercepts the selection
  3. opencode unselects the text and shows "copied" message
  4. OSC52 fails silently
  5. Nothing in clipboard, and the selection is gone

So users can't even manually select text and use Cmd+C as a fallback. The auto-copy-on-selection behavior with broken OSC52 makes the terminal completely unusable for copying text in VS Code Remote SSH.

This needs urgent attention - there's literally no way to copy text from opencode in VS Code Remote SSH right now.

@ErcinDedeoglu commented on GitHub (Feb 3, 2026): ## Update: Mouse selection workaround also broken The situation is actually worse than described. **Mouse text selection doesn't work as a workaround** because: 1. User tries to select text with mouse 2. On mouse button release, opencode **intercepts the selection** 3. opencode **unselects the text** and shows "copied" message 4. OSC52 fails silently 5. **Nothing in clipboard, and the selection is gone** So users can't even manually select text and use Cmd+C as a fallback. The auto-copy-on-selection behavior with broken OSC52 makes the terminal completely unusable for copying text in VS Code Remote SSH. **This needs urgent attention** - there's literally no way to copy text from opencode in VS Code Remote SSH right now.
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@ErcinDedeoglu commented on GitHub (Feb 3, 2026):

Additional finding: Shift+drag doesn't work either

Tried using Shift+click and drag to bypass TUI mouse handling - doesn't work. opencode still intercepts the selection.

Summary of what's broken in VS Code Remote SSH:

  • ❌ OSC52 clipboard (silently fails)
  • ❌ Mouse selection (intercepted, cleared, fake "copied")
  • ❌ Shift+mouse selection (still intercepted)
  • ❌ Manual Cmd+C (selection is gone before you can copy)

Literally zero ways to copy text from opencode in VS Code Remote SSH.

The only workarounds are:

  1. Downgrade to v1.1.48
  2. Use a different terminal (iTerm2 + direct SSH)
  3. Use opencode export to dump session to file

This is a critical regression that needs immediate attention.

@ErcinDedeoglu commented on GitHub (Feb 3, 2026): ## Additional finding: Shift+drag doesn't work either Tried using `Shift+click and drag` to bypass TUI mouse handling - **doesn't work**. opencode still intercepts the selection. **Summary of what's broken in VS Code Remote SSH:** - ❌ OSC52 clipboard (silently fails) - ❌ Mouse selection (intercepted, cleared, fake "copied") - ❌ Shift+mouse selection (still intercepted) - ❌ Manual Cmd+C (selection is gone before you can copy) **Literally zero ways to copy text from opencode in VS Code Remote SSH.** The only workarounds are: 1. Downgrade to v1.1.48 2. Use a different terminal (iTerm2 + direct SSH) 3. Use `opencode export` to dump session to file This is a **critical regression** that needs immediate attention.
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@okuuko commented on GitHub (Feb 3, 2026):

I'm hitting the same regression. My setup: opencode running in a headless NixOS microVM, accessed over SSH from Alacritty on a Hyprland/Wayland workstation.

Clipboard worked on 1.1.48, broke on 1.1.49.

The VM has no display server and no clipboard utilities (wl-copy, xclip, etc.) — OSC 52 through the SSH terminal is the only clipboard path. The old process.stdout implementation in 1.1.48 was actually working correctly in this setup. The switch to opentui's renderer.copyToClipboardOSC52 in #11744 broke it.

To confirm it's not a terminal issue: raw OSC 52 sequences sent manually from the VM still reach Alacritty and set the Wayland clipboard correctly:

printf '\033]52;c;%s\a' "$(echo -n 'test' | base64)"

The opencode TUI still shows "selection copied to clipboard" on text select, but nothing reaches the terminal/clipboard.

Environment:

  • opencode 1.1.49 (self-updated from 1.1.48 where clipboard worked)
  • Headless NixOS VM (no DISPLAY, no WAYLAND_DISPLAY)
  • SSH from Alacritty (OSC 52 enabled) on Hyprland/Wayland
  • No clipboard binaries in VM — relies entirely on OSC 52
@okuuko commented on GitHub (Feb 3, 2026): I'm hitting the same regression. My setup: opencode running in a headless NixOS microVM, accessed over SSH from Alacritty on a Hyprland/Wayland workstation. **Clipboard worked on 1.1.48, broke on 1.1.49.** The VM has no display server and no clipboard utilities (`wl-copy`, `xclip`, etc.) — OSC 52 through the SSH terminal is the only clipboard path. The old `process.stdout` implementation in 1.1.48 was actually working correctly in this setup. The switch to opentui's `renderer.copyToClipboardOSC52` in #11744 broke it. To confirm it's not a terminal issue: raw OSC 52 sequences sent manually from the VM still reach Alacritty and set the Wayland clipboard correctly: ```bash printf '\033]52;c;%s\a' "$(echo -n 'test' | base64)" ``` The opencode TUI still shows "selection copied to clipboard" on text select, but nothing reaches the terminal/clipboard. **Environment:** - opencode 1.1.49 (self-updated from 1.1.48 where clipboard worked) - Headless NixOS VM (no `DISPLAY`, no `WAYLAND_DISPLAY`) - SSH from Alacritty (OSC 52 enabled) on Hyprland/Wayland - No clipboard binaries in VM — relies entirely on OSC 52
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@zhiyozhao commented on GitHub (Feb 3, 2026):

Opencode osc52 support seems broken for me too. I am running opencode in tmux on a remote server through ssh. And have all my osc52 setup configured and tested, everything works fine (local iterm, ssh, tmux) except opencode. Does opencode always adopt osc52 or only adopt it when system clipboard fails?

OSC52 works with tmux, but not opencode

When dragging with mouse and release, opencode shows clipboard set and nothing in my local clipboard. However, at the same place(still in opencode), after i enter tmux copy mode with ctrl-b + [, mouse drag and release correctly update my local clipboard.

Environment

opencode: 1.1.49
server os: macos 15.6.1

@zhiyozhao commented on GitHub (Feb 3, 2026): Opencode osc52 support seems broken for me too. I am running opencode in tmux on a remote server through ssh. And have all my osc52 setup configured and tested, everything works fine (local iterm, ssh, tmux) except opencode. Does opencode always adopt osc52 or only adopt it when system clipboard fails? ### OSC52 works with tmux, but not opencode When dragging with mouse and release, opencode shows clipboard set and nothing in my local clipboard. However, at the same place(still in opencode), after i enter tmux copy mode with ctrl-b + [, mouse drag and release correctly update my local clipboard. ### Environment opencode: 1.1.49 server os: macos 15.6.1
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@Rooneyxu commented on GitHub (Feb 3, 2026):

Hi! I can reproduce this consistently in VS Code Remote-SSH on Ubuntu (headless / no GUI session).

Environment

Client: VS Code integrated terminal (Remote-SSH)

Remote: Ubuntu (no X11/Wayland session)

TERM_PROGRAM=vscode

OpenCode version:

✅ works: v1.1.48

❌ broken: v1.1.49 (and v1.1.50 “fallback to native clipboard” still doesn’t help)

Symptoms

In v1.1.49+, copying from the TUI (e.g. leader copy action / “Copied to clipboard” toast) reports success, but nothing is actually available to paste on the client machine.

In v1.1.48, copy/paste behaves as expected in my workflow.

@Rooneyxu commented on GitHub (Feb 3, 2026): Hi! I can reproduce this consistently in VS Code Remote-SSH on Ubuntu (headless / no GUI session). Environment Client: VS Code integrated terminal (Remote-SSH) Remote: Ubuntu (no X11/Wayland session) TERM_PROGRAM=vscode OpenCode version: ✅ works: v1.1.48 ❌ broken: v1.1.49 (and v1.1.50 “fallback to native clipboard” still doesn’t help) Symptoms In v1.1.49+, copying from the TUI (e.g. leader copy action / “Copied to clipboard” toast) reports success, but nothing is actually available to paste on the client machine. In v1.1.48, copy/paste behaves as expected in my workflow.
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@jc01rho commented on GitHub (Feb 4, 2026):

v1.1.50 still doesn't fix the issue. issue is still exist.

@jc01rho commented on GitHub (Feb 4, 2026): v1.1.50 still doesn't fix the issue. issue is still exist.
yindo commented 2026-02-16 18:09:53 -05:00
Author
Owner
Copy Link
Copy Source

@ErcinDedeoglu commented on GitHub (Feb 4, 2026):

v1.1.51 fixed.

@ErcinDedeoglu commented on GitHub (Feb 4, 2026): v1.1.51 fixed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8400
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?