Linux/Wayland: clipboard hangs after Ctrl-Z because wl-copy stays in OpenCode process group

Description

On Linux/Wayland, copying text from OpenCode and then suspending OpenCode with Ctrl-Z can leave the Wayland clipboard provider stopped.

The result is that pasting into the same terminal after suspending OpenCode hangs indefinitely.

This appears to happen because OpenCode spawns wl-copy in the same terminal process group. wl-copy then forks into the background to serve clipboard requests, but the clipboard-serving process remains in the same process group as OpenCode.

When Ctrl-Z is pressed, the terminal sends SIGTSTP to the foreground process group, stopping both OpenCode and the wl-copy clipboard provider.

The clipboard selection still references that stopped wl-copy process, so a subsequent paste waits on a provider that is suspended.

Running wl-copy in a separate session/process group with setsid fixes the issue completely.

Diagnosis

After reproducing the issue, wl-copy can be observed as stopped:

ps -o pid,ppid,pgid,sid,stat,tty,cmd -C wl-copy

The clipboard-serving wl-copy process has the same process group as OpenCode and its STAT contains T after Ctrl-Z.

Resuming the stopped wl-copy process with SIGCONT allows the paste to proceed again.

Confirmed workaround

Running OpenCode with a private wl-copy wrapper that creates a new session fixes the problem:

#!/usr/bin/env bash
exec setsid /path/to/real/wl-copy "$@"

With this wrapper scoped only to OpenCode:

1. Copy from OpenCode.
2. Press Ctrl-Z.
3. Paste into the same terminal.

The paste works normally.

Likely cause

OpenCode currently invokes wl-copy using a normal child-process spawn.

wl-copy backgrounds itself by forking, but does not create a new process group/session, so the clipboard provider remains part of OpenCode's terminal job-control process group.

This means Ctrl-Z suspends the clipboard provider along with OpenCode.

Possible fix

For the Wayland wl-copy backend, spawn the clipboard process in a separate process group/session so that it is not affected by terminal job-control signals sent to OpenCode.

For example, on Unix this could be implemented using a detached child process / separate process group for wl-copy specifically.

This probably should not be applied indiscriminately to every clipboard command, only to backends such as wl-copy whose clipboard ownership outlives the original write operation.

Environment

• OS: NixOS / Linux
• Display server: Wayland
• Compositor: Hyprland
• Terminal: Alacritty
• Clipboard backend: wl-copy / wl-clipboard

Related

#4283 reports more general Linux clipboard failures, but does not appear to cover this Ctrl-Z / process-group / SIGTSTP failure mode.

Plugins

headroom, serena

OpenCode version

1.18.17

Steps to reproduce

1. Run OpenCode in a Wayland terminal.
2. Copy some text from OpenCode.
3. Press Ctrl-Z to suspend OpenCode.
4. Paste into the shell that is now in the foreground in the same terminal.
5. The paste hangs indefinitely.

Pasting into another terminal before suspending OpenCode works normally.

Screenshot and/or share link

No response

Operating System

NixOS 26

Terminal

Alacritty