Skip to content

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

Closed
Closed
OSC52 clipboard doesn't work with VS Code Remote SSH - need fallback or detection#11909
Assignees
kommander
Labels
opentuiThis relates to changes in v1.0, now that opencode uses opentui

Description

@ErcinDedeoglu
ErcinDedeoglu
opened on Feb 3, 2026

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

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.

Activity

  1. github-actions
    assigned
    rekram1-node
    on Feb 3, 2026
  2. github-actions
    added
    opentuiThis relates to changes in v1.0, now that opencode uses opentui
    on Feb 3, 2026

  3. github-actions commented on Feb 3, 2026

    @github-actions
    github-actionsBot
    on Feb 3, 2026 – with GitHub Actions
    Contributor

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

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

  4. ErcinDedeoglu commented on Feb 3, 2026

    @ErcinDedeoglu
    ErcinDedeoglu
    on Feb 3, 2026
    Author

    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.

  5. ErcinDedeoglu commented on Feb 3, 2026

    @ErcinDedeoglu
    ErcinDedeoglu
    on Feb 3, 2026
    Author

    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.

  6. okuuko commented on Feb 3, 2026

    @okuuko
    okuuko
    on 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

  7. zhiyozhao commented on Feb 4, 2026

    @zhiyozhao
    zhiyozhao
    on Feb 4, 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

  8. Rooneyxu commented on Feb 4, 2026

    @Rooneyxu
    Rooneyxu
    on Feb 4, 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.

  9. jc01rho commented on Feb 4, 2026

    @jc01rho
    jc01rho
    on Feb 4, 2026

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

  10. rekram1-node
    assigned
    kommander
    and unassigned
    rekram1-node
    on Feb 4, 2026

  11. ErcinDedeoglu commented on Feb 4, 2026

    @ErcinDedeoglu
    ErcinDedeoglu
    on Feb 4, 2026
    Author

    v1.1.51 fixed.

  12. ErcinDedeoglu
    closed this as completedon Feb 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

opentuiThis relates to changes in v1.0, now that opencode uses opentui

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions