fix(main): requestSingleInstanceLock to prevent PTY loss on replace - #56
Merged
abasiri merged 2 commits intoAug 1, 2026
Merged
Conversation
… replace
On 2026-05-23, replacing the AppImage while Switchboard had active node-pty
sessions killed those sessions. The OS spawned the new binary which initialised
a second Electron process; the two instances raced and the running PTYs were
orphaned/killed.
Electron's requestSingleInstanceLock() is the standard fix:
- The first instance acquires the lock and continues normally.
- Any subsequent launch (e.g. the new AppImage binary after an in-place replace)
fails to acquire the lock, calls app.quit() immediately, and exits without
touching any PTY.
- A 'second-instance' listener on the first instance brings its main window to
the front, so the user gets visual confirmation the app is still running.
Changes:
- main.js: call app.requestSingleInstanceLock() before app.whenReady()
- Wrap app.whenReady() and all init code in the else-branch so it only runs for
the true first instance
- Register app.on('second-instance') to restore/focus mainWindow
Branch was 14 behind. The conflict was in the block this PR wraps: #32 landed on main and changed runScheduleCommand from a shell string to argv (runScheduleCommand(claudeArgv, …) plus quoteArgvForShell). This branch still carried the pre-#32 string form inside its new single-instance wrapper, so a naive resolution would have silently reverted the shell-injection fix. Resolved by keeping main's argv-based whenReady body and wrapping it in this PR's requestSingleInstanceLock else-branch. Verified with `git diff -w` against main: the only semantic change is the lock; everything else is the one-level reindent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #31.
Problem
Replacing the installed binary (e.g. an AppImage on Linux) while Switchboard has active
node-ptysessions can kill or orphan those sessions. The OS launches the new binary, which initialises a second Electron process; the two race on user-data and PTY pipes.I hit this on 2026-05-23 when overwriting
~/Applications/Switchboard.AppImagewhile a Claude CLI session was running — the running PTY died silently and the renderer reconnected to nothing.Fix
Electron's standard
app.requestSingleInstanceLock():app.quit()immediately, and exits without touching the existing process or its PTYs.'second-instance'listener on the first instance brings its main window to the front, so the user sees the existing app instead of nothing happening.The whole existing
app.whenReady().then(...)block is wrapped in theelsebranch so it only runs for the genuine first instance.Issue link
Also requested in #31 ("Feature request: single-instance mode (focus existing window when re-launched)") — same mechanism solves both the data-loss case and the UX issue.
Tested on
Linux / AppImage. The mechanism is platform-agnostic;
requestSingleInstanceLockis documented for all three desktop platforms.Notes