Bug: Concurrent pi processes crash on startup — lockSync with zero retries on global settings/auth

[joelreymont]

Bug

When multiple pi processes start simultaneously (e.g. spawned by a subagent extension for parallel task execution), the second process crashes with:

Error: Lock file is already being held
    at lockfile.lockSync(path, { realpath: false })

followed by:

error: No API key found for anthropic.

The process exits with a non-zero code and produces no useful output.

Root Cause

Both settings-manager.js and auth-storage.js use proper-lockfile's lockSync() with zero retries during startup:

// settings-manager.js:45
release = lockfile.lockSync(path, { realpath: false });

// auth-storage.js:36
release = lockfile.lockSync(this.authPath, { realpath: false });

proper-lockfile defaults to retries: 0 for lockSync, so if another pi process holds the lock (even briefly, during its own startup read), the call throws immediately.

Notably, auth-storage.js already has an async withLockAsync() method (line 63) that uses retries with exponential backoff — but the sync withLock() path (used during startup) does not.

Reproduction

# Two simultaneous pi processes — second one crashes
(pi --mode json -p --no-session --model claude-haiku-4-5 --tools bash "Task: echo A" 2>/tmp/a.txt >/dev/null) &
(pi --mode json -p --no-session --model claude-haiku-4-5 --tools bash "Task: echo B" 2>/tmp/b.txt >/dev/null) &
wait
cat /tmp/b.txt  # "Lock file is already being held"

With a 2-second delay between launches, both succeed:

(pi --mode json -p --no-session --model claude-haiku-4-5 --tools bash "Task: echo A" >/dev/null) &
sleep 2
(pi --mode json -p --no-session --model claude-haiku-4-5 --tools bash "Task: echo B" >/dev/null) &
wait  # Both succeed

Suggested Fix

Add retries to the lockSync calls in both files, matching the pattern already used in withLockAsync:

// settings-manager.js
release = lockfile.lockSync(path, {
  realpath: false,
  retries: { retries: 5, factor: 2, minTimeout: 100, maxTimeout: 2000 },
});

// auth-storage.js withLock()
release = lockfile.lockSync(this.authPath, {
  realpath: false,
  retries: { retries: 5, factor: 2, minTimeout: 100, maxTimeout: 2000 },
});

Current Workaround

In our subagent extension, we serialize process launches with an in-process mutex (LaunchGate) that acquires before spawn() and releases on first stdout data (indicating the child is past the lock-contention startup phase). This handles the single-parent case but not cross-instance contention.

Environment

• pi v0.55.0
• macOS arm64, Bun 1.3.3
• proper-lockfile ^4.1.2