[Bug] Windows: session lease can be permanently stuck, and a live lease can be reclaimed when owner.json is briefly unreadable

[andreolf]

Affected area

Coding agent and CLI

What happened?

Two related bugs in packages/coding-agent/src/core/session-lease.ts, both most likely to fire on Windows. (Both were in the now-closed #727; the second was independently confirmed by @BILLKISHORE.)

Bug 1 — a stale lease permanently blocks recovery on Windows. acquireSessionLease claims a lease by renaming a candidate dir onto the lease dir; on failure it reclaims the lease only when the error is EEXIST/ENOTEMPTY:

if (code !== "EEXIST" && code !== "ENOTEMPTY") { throw error; }
// ...
reclaimStaleLease(directory); // never reached on Windows

renameSync onto an existing non-empty directory reports EPERM/EACCES on Windows, so the error rethrows, reclaimStaleLease never runs, and a stale lease blocks the session indefinitely.

Bug 2 — a live lease can be reclaimed when owner.json is momentarily unreadable (more serious). readLeaseOwner collapses every failure into undefined, so the caller can't tell "owner.json absent" (no owner) from "owner.json unreadable" (transient I/O error) and falls through to reclaimStaleLease. On Windows a briefly held handle (antivirus, search indexer) makes an unreadable owner.json routine — so a live session's lease gets reclaimed and two processes believe they own the same session. Fixing Bug 1 widens this path on Windows.

Steps to reproduce

Identified by source inspection plus a unit-level repro (not a live end-to-end run — same basis as the review on #727). Deterministic repro for Bug 2, no Windows needed:

1. With session leases enabled, create a lease directory holding a valid owner.json for a process that is still alive.
2. Make owner.json present-but-unreadable: replace the file with a directory named owner.json in the lease dir, so readFileSync throws EISDIR — a stand-in for a transiently locked file.
3. From another process, call acquireSessionLease for the same session.
4. Observe: the lease is reclaimed instead of being treated as held by the live owner.

Bug 1 surfaces on Windows when renameSync onto the existing lease dir returns EPERM/EACCES instead of EEXIST/ENOTEMPTY, so the reclaim path is never reached.

Expected behavior

• Bug 1: on Windows, a genuinely stale lease should be reclaimed and the session should start — EPERM/EACCES on an existing rename target should be treated like EEXIST/ENOTEMPTY.
• Bug 2: when owner.json exists but can't be read (transient error, not a missing file), the lease should be treated as held by a live owner and NOT reclaimed — matching isProcessAlive, which returns true on EPERM. Only a genuinely absent owner.json should be reclaimable.

Prime Agent version

Identified from source on main (paths also present in the 0.7.x line); not tied to a single running build.

Environment

Analysis performed on macOS. Affected platform is Windows (Bugs 1 and 2, due to renameSync error codes and routine transient file locking); Bug 2's repro is cross-platform.

Additional context

Suggested direction:

• Bug 1: also accept EPERM/EACCES on win32 in the rename-error filter.
• Bug 2: distinguish absent / unreadable / owner in readLeaseOwner and treat unreadable as a live owner (mirror isProcessAlive's EPERM handling).

Both were in the now-closed #727, where Bug 2 was independently confirmed by @BILLKISHORE. Happy to provide a PR with tests if a maintainer wants to pursue this.

[chimin-roh]

Confirming on Windows 11. Still present in v0.8.0 — core/session-lease.ts is byte-identical between 0.7.2 and 0.8.0, including the guard at :268:

if (code !== "EEXIST" && code !== "ENOTEMPTY") throw error;

On Windows, rename onto an existing directory fails with EPERM, not EEXIST/ENOTEMPTY, so the reclaim path is unreachable and the stale lease is never collected. Observed behaviour matches: once it happens it does not clear itself, and a reboot does not help — the directory has to be removed manually.

Reproduced after force-killing the process tree (taskkill /f /im node.exe), which leaves the lease directory behind.