What
main.ts does not call app.requestSingleInstanceLock(), so two CodeV instances can run at once. Both write the user-level stores in ~/.config/codev/ (session-marks.json, session-lists.json) with read-modify-write over the whole file, and neither takes a lock or checks a version before renaming — so the later writer silently drops the earlier writer's change.
Raised by cubic on PR #147 (thread — the mutateStoreFile comment). It is not new to that PR: the marks store has worked exactly this way since PR #136; #147 only moved the code into src/atomic-json-store.ts.
Why the fix is a single-instance lock, not a file lock
A menu-bar app is meant to run once. The realistic way to get two writers is a second launch (dev yarn start beside the installed app, or a double-open), and Electron's answer to that is one call:
if (!app.requestSingleInstanceLock()) app.quit();
app.on('second-instance', () => switcherWindow?.show());That closes the whole class. A file lock or compare-and-swap in the store would guard against a scenario the app does not otherwise support, at the cost of a lock file to clean up after crashes.
Caveat to decide before doing it: the dev workflow runs yarn start while the installed app may be up. With the lock, the second one quits immediately — which is arguably what should happen, but it changes how dev mode behaves. Worth a one-line note in CLAUDE.md's Dev Mode Gotchas.
Priority: low. Filed rather than folded into #147 because it changes app-launch behaviour, which that PR is not about.
🤖 On behalf of @grimmerk — generated with Claude Code
What
main.tsdoes not callapp.requestSingleInstanceLock(), so two CodeV instances can run at once. Both write the user-level stores in~/.config/codev/(session-marks.json,session-lists.json) with read-modify-write over the whole file, and neither takes a lock or checks a version before renaming — so the later writer silently drops the earlier writer's change.Raised by cubic on PR #147 (thread — the
mutateStoreFilecomment). It is not new to that PR: the marks store has worked exactly this way since PR #136; #147 only moved the code intosrc/atomic-json-store.ts.Why the fix is a single-instance lock, not a file lock
A menu-bar app is meant to run once. The realistic way to get two writers is a second launch (dev
yarn startbeside the installed app, or a double-open), and Electron's answer to that is one call:That closes the whole class. A file lock or compare-and-swap in the store would guard against a scenario the app does not otherwise support, at the cost of a lock file to clean up after crashes.
Caveat to decide before doing it: the dev workflow runs
yarn startwhile the installed app may be up. With the lock, the second one quits immediately — which is arguably what should happen, but it changes how dev mode behaves. Worth a one-line note inCLAUDE.md's Dev Mode Gotchas.Priority: low. Filed rather than folded into #147 because it changes app-launch behaviour, which that PR is not about.
🤖 On behalf of @grimmerk — generated with Claude Code