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

Activity

1. github-actions

   assigned

   rekram1-node

   on Jan 12, 2026
2. github-actions

   added

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

   on Jan 12, 2026
3. github-actions commented on Jan 12, 2026

   

   github-actionsBot

   on Jan 12, 2026 – with GitHub Actions

   Contributor

   More 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.
4. aaajiao commented on Jan 12, 2026

   

   aaajiao

   on Jan 12, 2026

   Author

   More actions

   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
5. aaajiao commented on Jan 12, 2026

   

   aaajiao

   on Jan 12, 2026

   Author

   More actions

   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
6. aaajiao commented on Jan 12, 2026

   

   aaajiao

   on Jan 12, 2026

   Author

   More actions

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

   closed this as completedon Jan 12, 2026