Repository navigation
[BUG]: desktop has no single-instance guard; repeated Dock clicks spawn multiple main processes #56396
Description
Summary
Repeated clicks on the Dock icon during a stuck launch each spawn a new main process, each with its own log folder. There is no single-instance guard, so a stuck launch can multiply.
Environment
- macOS 27 (Darwin 27.0.0), Apple Silicon
- OpenCode Desktop 2.0.29 (prod channel,
ai.opencode.desktop)
Reproduction
- Get the app into the state where a Dock click does not paint the window (see [BUG]: macOS desktop: Cmd+Q leaves a half-dead instance, and the next Dock click stalls the renderer #56394).
- Click the Dock icon repeatedly.
- Three main processes accumulate in 24 minutes, each with its own log folder.
Expected
A second launch should focus the existing instance, or exit, rather than start a second main process.
Notes
Observed by richardding alongside #56394; filed here at their request.
Activity
opencode-agent commentedon Oct 17, 2026
Thanks for the detailed report. Reproducing this needs the packaged desktop app on macOS (Dock launches and the stuck state after Cmd+Q from #56394), which our sandbox can't provide, so a maintainer with a Mac will need to look at it.
What the code shows: 2.0.29 does have a single-instance guard. The desktop entry point calls
app.requestSingleInstanceLock()and quits right away if another instance holds the lock. Also, the per-run log folder is only created after a process gets that lock. So each of the three log folders you saw likely belongs to a process that got the lock. That points to the half-dead instance from #56394 giving up the lock while it quits but never exiting, rather than to a missing guard. This hasn't been confirmed yet.Related:
Te-River commentedon Oct 17, 2026
The bot is right and I was wrong on the premise — 2.0.29 does have
app.requestSingleInstanceLock(), and the per-run log folder is only created after a process wins it. So the three folders mean three processes each held the lock, which is not a missing guard.Corrected reading: the half-quit instance from #56394 gives the lock up while it quits but never exits, so the next Dock click finds no holder and starts fresh — landing on the half-dead one. That makes this a symptom of #56394 rather than an independent defect.
Closing this as a duplicate of #56394 — the observable (multiple processes) is explained by the quit path, and there is no separate single-instance defect to fix. If someone shows a second process holding the lock while the first is still alive, it can reopen.