[BUG] Clipboard copy only works first time after upgrading to v1.1.14 (regression from v1.1.13)

[aaajiao]

Description

After upgrading from v1.1.13 to v1.1.14, clipboard copy only works the first time. Subsequent copy operations fail silently (shows "Copied to clipboard" but nothing is actually copied).

Works in: v1.1.13 ✅
Broken in: v1.1.14 ❌

Environment

• OS: macOS (running OpenCode in Docker container via OrbStack)
• Terminal: Ghostty
• OpenCode version: 1.1.14

Ghostty config

copy-on-select = clipboard
clipboard-read = allow
clipboard-write = allow

Steps to Reproduce

1. Start OpenCode v1.1.14 in Docker container
2. Select text and copy (first time) → ✅ Works
3. Select different text and copy (second time) → ❌ Fails
4. Subsequent copies continue to fail

Expected Behavior

All copy operations should work consistently, as they did in v1.1.13.

Suspected Cause

This regression may be related to mouse interaction changes introduced in v1.1.14:

• feat(tui): add mouse hover and click support to autocomplete #7820: feat(tui): add mouse hover and click support to autocomplete
• feat(tui): add mouse hover and click support to questions tool #7905: feat(tui): add mouse hover and click support to questions tool

Related Issues

• fix(tui): prevent UI freezes from clipboard operations and event loop #7395: fix(tui): prevent UI freezes from clipboard operations and event loop (addresses Bun GC bug)
• Copy Text "Copied to clipboard" does never work #7048: Copy Text "Copied to clipboard" does never work

Workaround

Downgrade to v1.1.13

[github-actions]

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

• Copy Text "Copied to clipboard" does never work #7048: Copy Text "Copied to clipboard" does never work

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

[aaajiao]

Update: Tested v1.1.15

New Findings

After upgrading to v1.1.15, the behavior has changed:

1. v1.1.15 no longer calls xclip/xsel - It appears to use OSC52 instead
2. Copy to Mac clipboard works - Content is successfully copied to macOS clipboard
3. But there's a new issue: Cannot paste immediately within TUI

Reproduction Steps (v1.1.15)

Scenario	Result
Copy in TUI → Switch to another app → Paste there	✅ Works
Copy in another app → Paste in TUI	✅ Works
Copy in TUI → Switch app → Switch back → Paste in TUI	✅ Works
Copy in TUI → Immediately paste in TUI (no app switch)	❌ Fails

Environment

• macOS + Docker (OrbStack)
• Ghostty terminal with OSC52 enabled:

  clipboard-read = allow
  clipboard-write = allow
  

Analysis

It seems Ghostty (or the TUI) requires a focus change to sync the clipboard after OSC52 write. The clipboard content is there (can paste in other apps), but the same terminal window cannot read it immediately.

This might be:

1. A Ghostty issue with OSC52 clipboard sync
2. Or an OpenCode TUI issue with clipboard state management

[aaajiao]

Update: Root cause found - NOT an OpenCode bug

After deeper investigation, I discovered the actual root cause was in my Docker wrapper (OCD), not OpenCode itself.

What happened:

• My wrapper spawns fswatch to monitor IPC files for clipboard bridging
• Due to a process cleanup bug, 130+ zombie fswatch processes accumulated over time
• Each zombie was still watching the same IPC files
• When OpenCode wrote to the clipboard IPC file, multiple fswatch processes triggered simultaneously
• This caused race conditions that made clipboard operations appear to fail

The fix:

• Fixed the process group cleanup in my wrapper
• Now fswatch processes are properly terminated on exit
• Clipboard works reliably again

Conclusion:

This was not an OpenCode v1.1.14 regression. The timing was coincidental - the zombie processes had accumulated to a critical mass around when I upgraded.

I apologize for the noise. Feel free to close this issue.

---

For reference, the fix: aaajiao/opencode-on-dorker#78

[aaajiao]

Closing - root cause was in my wrapper, not OpenCode. See comment above.