bug(setup): two main processes share one state dir with no process lock (dev + installed app) #993

Expected

Only one Agent Code main process may own the shared state directory at a time. acquireStateProcessLock (src/main/storage/processLock.ts) is supposed to show "Agent Code is already running" and quit any second process that would share state.

Actual

On 2026-09-18 both instances ran simultaneously against ~/.config/agent-code:

• dev build: Electron from node_modules/electron (PID 77576, bundle id of raw Electron)
• installed build: /Applications/Agent Code.app (com.agentcode.app)

while ~/.config/agent-code/agent-code.process-lock.json did not exist at all — no live owner, no stale lock, just absent, despite the dev process actively using the directory (control-history writes, layout mutations).

Observed fallout in the same window: all OpenCode panes erroring in one instance, and a fresh agent failing on startup. Not yet proven causal, but shared-state racing between two main processes is the prime suspect.

Why the current guards miss this

1. app.requestSingleInstanceLock() (src/main/index.ts:357) is per-bundle-id, so a dev Electron and the installed app never see each other.
2. The state process lock should still catch it — unless one of the processes never acquired it (early startup failure path?) or released it while staying alive (the before-quit/will-quit paths). An empty/absent lock while a live process actively writes STATE_DIR suggests the lock lifecycle has a hole.

Reproduce / investigate

• Launch the dev app, launch the installed app, inspect the lock file during and after.
• Suspects: startup-throw path releasing/never-acquiring the lock but continuing; a crash-then-relaunch cycle that cleared the file while the old process lived; install-time migration touching the lock.

Impact

Any user who runs a dev checkout and the installed beta together — which is exactly the current workflow — can silently corrupt shared state.

Environment

macOS, dev build at 0b744b8, installed v0.0.2-beta.1, both running 2026-09-18 ~01:00 UTC.