Session lock is published under the shared Claude worker-pool daemon pid, so a sibling session in the same pool passes ownership

[karotkriss]

Summary

When a firstmate session acquires the session lock through Claude Code's reparented per-user worker pool, bin/fm-lock.sh publishes the shared pool daemon's pid rather than the acquiring session's own pid. Because ownership is decided by ancestry membership, any other Claude session served by that same per-user pool then passes the ownership test for that home. That breaks the exclusivity the lock exists to provide.

This is pre-existing behaviour on unmodified main. Filing it separately because it was surfaced during review of #2839, which is deliberately scoped to a different mechanism and is inert on this path.

Reproduction path

1. state/.lock names a prior session that is now dead.
2. A new session starts with CLAUDE_PID=700, but its tool call is served from the pool, so its ancestry reaches only 320 -> 310 -> 300 -> 1 and never reaches 700.
3. me=$(fm_harness_ancestry_pid) therefore resolves to the shared pool daemon pid 300.
4. The stale lock is replaced and publication records 300.
5. A different Claude session served by that same per-user pool also has 300 in its ancestry, so fm_session_lock_owned_by_self returns true for it against the same home.

Evidence that this is pre-existing

On unmodified main:

• bin/fm-lock.sh line 36 already derives the published identity purely from ancestry:

  me=$(fm_harness_ancestry_pid) || { echo "error: cannot locate harness process in ancestry" >&2; exit 1; }

  Under a pool reparented to init, that is the daemon pid, so main publishes 300 in this scenario.
• bin/fm-session-lock-lib.sh fm_session_lock_owned_by_self already decides ownership by ancestry membership of the recorded pid, so a sibling session under the same pool already satisfies it.

Both halves of the defect are therefore present without any change applied.

Impact

Two live sessions sharing one per-user worker pool can each believe they own the same home's session lock. Lock-gated operations - spawn, steer, merge, wake drain, supervision repair - are then no longer serialized between them.

Suggested direction

The identity that gets written needs resolving at the shared acquisition boundary, after the existing lock has been proven free or stale, rather than being taken from an ancestry walk that cannot see past the pool. Any fix should preserve the existing rule that a published session id alone must never let a caller claim a lock a different live session currently holds.

Note that #2437 already proposes a durable session-identity binding recorded at acquisition, which addresses this class of problem directly; this issue may be best resolved as part of whichever ownership mechanism the maintainers select.

[kunchenguid]

Speaking as Kun's firstmate:

Still on current main (197afbb79f8b). A Claude worker-pool session publishes the shared daemon pid, so a sibling session in the same pool passes ownership. Distinct from #2314 (false refusal when ancestry misses CLAUDE_PID). Help open #2839 and #2437; do not compete. #2839 is scoped to the refusal path and is inert on this publication hole.

VISION: exclusive lock is authority; a sibling that passes ownership is a hidden grant. Restart-as-non-event fails if two primaries believe they own the home. Left open and labeled ready-for-pr. Not a merge vote.

[kunchenguid]

Speaking as Kun's firstmate:

VISION: aligns. Exclusive session authority is a refusal path: spawn, steer, merge, wake drain, and supervision repair must belong to one live session. A lock that a sibling pool session can inherit is a dishonest gate — it authorizes work the captain did not hand that session. Scripts own that identity check; a vendor process tree is not allowed to infer it.

Contributor report (karotkriss): under Claude Code's per-user worker pool, bin/fm-lock.sh publishes the shared pool daemon pid because me=$(fm_harness_ancestry_pid) cannot see past the reparented pool. fm_session_lock_owned_by_self then treats any sibling served by that same pool as the owner. Filed as pre-existing on unmodified main, surfaced in review of #2839 (scoped to a different mechanism and inert on this acquire path). Points at #2437's durable session-identity binding as the class of fix.

Inspected current main f170cedeb735759e9547a5b9de1a26eca7ea6d71 (not the contributor's tree):

• bin/fm-lock.sh:36 still sets me=$(fm_harness_ancestry_pid) before the stale/missing-lock replacement at lines 58–97. After a dead prior owner, publication writes that ancestry pid verbatim.
• bin/fm-session-lock-lib.sh fm_harness_ancestry_pids walks ≤16 hops, extends through contiguous Claude matches, and stops at pid ≤ 1. A pool chain 320 -> 310 -> 300 -> 1 therefore publishes 300.
• fm_session_lock_owned_by_self (lines 163–176) is still ancestry membership of the recorded pid. A second live Claude session whose tool ancestry also contains 300 passes for the same home.
• No adapter on this SHA recovers a stable session pid at the acquire/write boundary. CLAUDE_PID is unused on main.

Related open work — do not compete; extend one of these rather than opening a third lock-identity PR:

• Session-lock self-ownership check fails under Claude Code's daemon-based Bash execution (false 'another session' refusal) #2314 (already ready-for-pr) is the false-refusal twin: lock holds the real session pid, later pool-served checks cannot prove it.
• fix(bin): recognize Claude session locks across worker pools #2839 (karotkriss, fm/fm-2314-lock-daemon) widens read ownership from published CLAUDE_PID for Session-lock self-ownership check fails under Claude Code's daemon-based Bash execution (false 'another session' refusal) #2314. Its own pipeline still flags this issue's write path: stale/missing lock + CLAUDE_PID=700 + ancestry 320 -> 310 -> 300 -> 1 publishes 300 because adoption cannot select 700 when the lock names someone else. That residual is this ticket.
• fix(bin): let a session prove it owns its own fleet lock from a reparented pool #2437 (Kallas95) records a durable state/.lock.session binding at acquisition. That write-side identity is the mechanism this issue asked for; it is still open and must stay compatible with a live foreign lock remaining unclaimable from CLAUDE_PID alone.

ready-for-pr is a queue label, not a merge vote.