a recorded identity that is never checked against the process it names: pidfile stops and the Windows detached handle both signal a pid on the strength of a written-down value

[davidfarah2003]

The defect is not a missing check. It is a stored value that reads as verified because it was written down.

ProcessOwner records a startedAt (packages/workspace/src/maintenance.ts:46), written the moment a process is spawned: new Date().toISOString() beside the pid (maintenance.ts:728, and identically at implementations/cli/src/commands/up.ts:928, up.ts:2025, implementations/cli/src/lib/restore.ts:604, implementations/cli/src/lib/isolated-broker.ts:405). It survives in journals, listener proofs and claim records. It is schema-validated on read (maintenance.ts:955) and compared field-by-field (maintenance.ts:1109, up.ts:1174). Everything about its treatment says evidence. And nowhere in the repo is it ever compared against the live process it describes: localProcessOwnerStatus (maintenance.ts:731) checks the hostname and sends kill(pid, 0) (maintenance.ts:734), and the only comparisons startedAt ever enters are record against record. A declaration is being consumed as a fact.

The shaped Windows handle in detached-spawn.ts is the same move one layer down. To outlive its parent, the launcher gives up the one identifier the OS guarantees not to reuse (the process handle, closed inside the native script at detached-spawn.ts:92) and hands back a pid-only ChildProcess (detached-spawn.ts:34) whose kill() forwards straight to process.kill(pid, signal) (detached-spawn.ts:41). The number is the recorded identity token, and it is never checked against the thing it claims to identify.

Both are declarations treated as facts. That is what makes them one class rather than two coincidentally related bugs, and why this is one issue: the remedy is not "add a check" to each site, it is to make the recorded value load-bearing, and to refuse the destructive action when it cannot be compared.

The mechanism, walked

A daemon dies without cleanup (SIGKILL, OOM, reboot, power loss); its pidfile survives, because preserving records on unconfirmed death is exactly what these paths correctly do. The OS later reuses the number for an unrelated process owned by the same user: an editor, a build, another service. A later cotal down reads the pidfile, parses the number, probes it, hears alive, sends SIGTERM, and escalates to SIGKILL when the stranger does not exit. Every weaker doubt is already handled fail-closed (unparsable content, unknown probes, refused signals, unconfirmed deaths); "alive, but is it the same process?" is the one question the stop paths never ask, and the one question their own recorded startedAt was positioned to answer and never does. Worse than absent, the value supplies the appearance of the answer: a record carrying a timestamp reads as a verified identity to every reader, human or code, that does not go looking for the comparison that does not exist.

What is already right, which is what makes the gap easy to miss

This is not a repo missing a safety culture; it is a repo whose stops stop one question short.

• processStartToken in packages/workspace/src/advisory-lock.ts:68 IS the real pid-reuse check on Linux and macOS: /proc/<pid>/stat field 22 and ps -o lstart=, recorded at acquire and compared at inspect (advisory-lock.ts:156). And it is not sitting unused in one file: the extension mutation markers (packages/workspace/src/extension-mutation.ts:135, :148, :208) and the seed reconcile lock (implementations/cli/src/seed/lock.ts:113, :162) record and compare start tokens the same way. Every consumer is a lock or mutation coordination, and no stop path has one. That is the sharpest form of the gap: the repo reaches for this check whenever it needs to know whether a recorded owner is still real, and never reaches for it before sending a signal.
• The liveness probe is a deliberate tri-state (packages/workspace/src/pid.ts:62): only ESRCH proves death, EPERM means alive under another user, everything else is unknown and never acted on as death.
• stopManager reads argv before signalling on POSIX (implementations/cli/src/lib/manager-proc.ts:281) and refuses when the live pid is provably not a manager: "A LIVE pid that is provably NOT a manager is never signalled."

So the permissive sites below sit in the middle of a codebase that refuses on weaker doubts everywhere else. The gap is easy to miss precisely because the surrounding code is good: the hard parts (torn writes, errno semantics, mutual exclusion between concurrent stoppers) are done, and startedAt's paper trail looks like the last one. What remains is the one fact that requires cooperation from the OS rather than from our own bookkeeping.

The sites

Two rows below cite origin/feat/up-daemonize-persist rather than main, because those files do
not exist at HEAD yet: they arrive with an unmerged branch, so those citations will move with it and
lapse entirely if it never lands. The pidfile rows stand on main on their own, and the argument
does not depend on the Windows rows.

Site	What it does today	What it cannot prove
packages/workspace/src/pid.ts:62 probeLiveness	process.kill(pid, 0) plus the errno mapping	Which process the number names. It answers existence, never identity.
packages/workspace/src/pid.ts:111 readProcessCommand	argv via /proc or ps on POSIX; hardcoded unreadable on win32 (line 112)	Any identity fact on win32, by explicit decision (see the win32 section)
packages/workspace/src/maintenance.ts:731 localProcessOwnerStatus	kill(pid, 0) and a hostname check; startedAt sits in the same record (maintenance.ts:46, written at :728)	That the live pid is the recorded process. The recorded start time is never compared against the OS's own start time for that pid; startedAt is only ever compared record-against-record (maintenance.ts:1109), never against the process
implementations/cli/src/commands/down.ts:237 stopLocalProcess	The generic stop for every registered component (manager, delivery, auth, broker, web, extension processes): parse pid, coordinate the .stopping marker, SIGTERM (line 314), SIGKILL (line 332), await ESRCH	Attribution of any kind. No readProcessCommand, no start token, no owner comparison anywhere in its body
implementations/cli/src/lib/auth-proc.ts:224 stopAuthService	parse, probe, SIGTERM, await confirmed death	The pid's identity. No argv check even on POSIX, though argv reading is imported one file over in manager-proc
implementations/cli/src/lib/delivery-proc.ts:243 stopDelivery (on origin/feat/up-daemonize-persist)	same shape as stopAuthService	same
implementations/cli/src/lib/detached-spawn.ts:34 windowsDetachedChild (on origin/feat/up-daemonize-persist)	returns a pid-only ChildProcess whose kill() forwards to process.kill(pid, signal) (line 41) after the native launcher closed its process handle	The identity half of the shape it already names. assertDetachedChildExitObservable (line 52) handles the observability half ("A detached child may be signalable without being observable"); identity has no seam at all
implementations/cli/src/lib/isolated-broker.ts:362 stopByPid	signals pids read from the durable handshake file after an alive() check	Identity; and its ProcessOwner.startedAt (isolated-broker.ts:405) is stamped with the time the coordinator READ the handshake, not the process's start, so it could not satisfy a real start check even if one existed
implementations/cli/src/commands/down.ts:368 preserveStateDown	finds this root's mesh with mesh.root === root, a raw string equality on filesystem paths, on the --preserve-state path	That the two spellings name the same directory. meshesForRoot (packages/workspace/src/mesh-registry.ts:276) exists for exactly this and warns that "a raw === silently misses" (symlinked roots, macOS /var versus /private/var, Windows 8.3 short names); the plain down path already routes through it (down.ts:190, via removeMeshesByRoot), target resolution applies the same canonicalized predicate (packages/workspace/src/mesh-target.ts:364), and only this call bypasses it. Consequence is misidentification (a recorded mesh reads as absent, so the recovery verb refuses where found 0), not a signal

Callers worth naming: the Ctrl-C teardown of a foreground up stops the delivery daemon, manager and auth service by pidfile (implementations/cli/src/commands/up.ts:961), under its own comment "All kill by pidfile, symmetric" (up.ts:955), and only the manager leg has the argv check. cotal down manager does not go through stopManager at all; it goes through the generic stopLocalProcess, so even on POSIX the argv check does not cover the documented stop verb. The presence direction carries the same unproven claim without the destruction: implementations/web/src/web.ts:216 treats a live prior pid as "web dashboard is already running", which pid reuse turns into a false-up.

Why this is one class, not two issues

The pidfile paths and the Windows handle are the same defect on both sides of one spawn. The daemon side writes a record carrying only a number; the stop side signals a number. The Windows launcher in detached-spawn.ts is the newest and purest instance of the class: to survive the parent it gives up the process handle, the one identifier the OS guarantees not to reuse, keeps the number, and hands back an object whose kill is process.kill(pid, signal). The file already contains the shape of the problem half-recognized: the seam's doc says the handle is returned "after the native Windows launcher closes its process handle", and assertDetachedChildExitObservable refuses to treat absent event methods as evidence of exit. The observability half of "a pid without a handle" got a contract; the identity half got nothing.

Filing these as two issues would be the wrong cut for a concrete reason: a reader with two issues closes the cheap one and feels finished. The pidfile half looks like plumbing (add a token beside the pid on POSIX), and closing it alone leaves every Windows stop, including the new launcher path, signalling pids it cannot attribute while the class reads as handled. Closing the Windows half alone leaves cotal down, the highest-frequency destructive verb in the CLI, signalling unproven pids on every platform. One class, one issue: a signal sent from a record requires the record's identity claim to be checked against the live process, everywhere the repo sends one.

A fourth surface belongs in the same class, kept distinct from the signalling paths because its consequence is misidentification rather than a signal: preserveStateDown compares a recorded root by raw === (down.ts:368) where the registry's own doc says that comparison "silently misses" and ships the canonicalized one this call bypasses (mesh-registry.ts:274, mesh-target.ts:364). A recorded root compared by an equality that cannot detect the case it exists to catch, a start time treated as verified because it was written: the same habit wearing a different record.

The rule this repo already follows

Nothing here needs a new doctrine. The repo's existing rule, applied uniformly, covers every site: when identity cannot be established, refuse the destructive action.

• down.ts:135: "Fail CLOSED: an unselected dependant that MIGHT be running (including one behind an unattributable/unknown pidfile) blocks a stop-last shutdown".
• stopLocalProcess itself refuses unattributable content (down.ts:309), a refused signal (down.ts:325), and an unconfirmed death (down.ts:336), preserving the record each time.
• assertManagerRecordReplaceable (manager-proc.ts:174) refuses to start over an unknown or unattributable record.
• advisory-lock.ts treats an unobtainable token as active/unknown: "NEVER reclaimed on the missing token alone; only a PID-dead owner is reclaimable" (advisory-lock.ts:28). This is the repo making a recorded identity load-bearing: a token that no longer matches means recycled, and matching is checked against the live process, not against another record.
• materializeSecretToFile (packages/workspace/src/auth-paths.ts:388) fails loud on an absent key rather than materializing an empty credential.
• maintenance.ts:1141 throws listener-owner-ambiguous when ownership cannot be proven locally.

The contrast that sharpens the rule: divergentCwdAnchor (auth-paths.ts:429) is deliberately a REPORTER that never throws and never chooses, and that is correct, because it is a diagnostic with no destructive action behind it ("a detector that can abort its caller is that same defect once more, wearing the cwd's failure instead of its answer"). The distinction is not "silence bad, throwing good"; it is that a destructive action requires proof its target is what the record says. Every stop path in the table has a destructive action behind it, and none of them (except stopManager on POSIX) has the proof.

Suggested fix shape: make the recorded value load-bearing

The remedy is not "add a check" at N sites; it is to make the value that is already recorded answer for itself, and to refuse the destructive action when it cannot be compared. The shape is the advisory-lock mechanism generalized: at write time, record the process start token next to the pid in every pidfile the stop paths read; at stop time, compare the recorded token against the live process and refuse to signal on mismatch, which is verbatim the rule at advisory-lock.ts:156 ("A recorded start token that no longer matches means the PID was recycled: the original owner is gone (stale)."). One shared identity contract beside pid.ts, consumed by stopLocalProcess, stopAuthService, stopDelivery, stopManager, and the launcher's windowsDetachedChild, rather than five site-local patches. The migration question (what a reader does with a legacy bare pid, where no token was ever recorded) is part of the design, not something to settle in this issue. On POSIX, argv attribution can remain the manager's extra check. No patch is proposed here on purpose; the win32 half has an open question first.

The win32 question is open, and the existing position is argued

The gap on win32 is not an oversight being caught; it is a reasoned position being revisited. The rationale is written out at advisory-lock.ts:69:

Windows has no cheap, STABLE start token here: /proc is absent and a ps on PATH (MSYS/Git) returns inconsistent output between calls, which would make the SAME live lock read differently from the acquirer vs a reader and be misjudged stale. Per the no-token rule, return undefined so a live PID keeps the lock active/unknown (bounded-wait is the backstop) rather than a false reclaim.

And readProcessCommand's doc carries the same argument for argv (pid.ts:106): a platform that cannot look "behaves exactly as every platform did before this existed", because attribution may only downgrade a record on affirmative evidence that the live process is something else.

Two things change when the same question is asked in front of a signal rather than a lock. First, the lock's safety argument does not transfer: an absent token is safe there because a bounded wait is a real backstop, while a stop that proceeds on an unproven pid has nothing behind it; the destructive act itself is the fallback, so the thing being degraded is someone else's process. Second, the requirement is different: the lock polls, so its token must be cheap; a stop runs once, so its token only needs to be stable. And a stable win32 start time is not unobtainable, it is merely not free: the launcher itself held the process handle a moment before closing it (detached-spawn.ts:92 closes pi.hProcess in the same script that returns the pid), and the PowerShell Add-Type seam it already uses can read a process creation time without introducing new machinery of a different kind.

Does the no-fallbacks doctrine ("Throw if something is not supported in the current environment or config, rather than silently degrading", AGENTS.md:161) already decide this? Mostly yes, with one honest counterargument. Proceeding when identity cannot be established is a silent degradation: the stop reports a clean teardown over a signal sent to an unverified number, which is the shape the doctrine exists to prevent. The counterargument is the repo's own precedent that "cannot be represented on this platform" is sometimes not a refusal: manager-proc.ts:127 treats a chmod a Windows volume cannot represent as not a reason to refuse starting the manager. But that precedent covers hygiene around an action (a defence-in-depth file mode), not the identity of the target of the action; a kill whose target is unproven is a different category from a log whose mode is loose. So the reading holds on the stop side, and it would make the stop refuse on win32 until a token mechanism exists, exactly as it refuses on every weaker doubt today. What the doctrine does not settle is whether that refusal ships as the interim behaviour or arrives together with a win32 token, and that tradeoff (a platform whose stops currently work, versus the correctness of a destructive verb) is the open design decision.

Why this is worth fixing rather than noting

A stop that signals a pid it cannot attribute is indistinguishable, in every line it prints, from one that can, right up until the number belongs to something else. The failure is destructive outside the repo's blast radius: the process at the other end belongs to the operator and did nothing wrong. The paths involved are not rare corners; cotal down is the documented heal verb, and the Ctrl-C teardown of a foreground up runs the pidfile stops on every dev session. The reuse window is narrow, but this codebase already pays the cost of refusing on every other narrow window (torn pidfiles, seccomp errnos, refused signals), and on Linux the check is already written, tested, and sitting in advisory-lock.ts. Windows is where the real decision is, and the new detached launcher is about to make the class larger: every Windows stack it starts will be stopped through a handle-shaped object whose only identity is a number that was never asked to prove itself.

[davidfarah2003]

A fourth instance of this shape turned up while building the guard that closes #884, and it is worth recording here because it is the same defect wearing test clothing rather than production clothing.

The guard refuses a down whose resolved root is not the sandbox's own. Its suite asserted that refusal by pointing the call at a foreign root, and it passed. Replacing the guard's entire identity comparison with return true left the suite passing as well: with the check disabled, a probe showed the guard permitting a teardown against a real foreign checkout while the suite still reported success.

The cause is that the foreign root in the assertion was a path that was never created. Statting it threw, the catch returned false, and the refusal came from the directory being absent rather than from the identity differing. That assertion holds identically under a correct implementation, an inverted one, and a hardcoded true. A cell that passes under every implementation of the thing it names is not testing that thing, and it reads as coverage in every report.

The reason it could not simply be fixed in the test is the part that belongs in this issue: identity-differs and directory-absent produced the same refusal, so no assertion could tell them apart. Both should refuse, but they are different conditions. One says the sandbox was built wrong; the other says the teardown escaped its sandbox. Collapsing them into a single signal costs the operator the diagnosis at the moment they most need it, and it makes the correct behaviour unprovable as a side effect. The test was unwritable because the guard was conflating two states, not because the test was written carelessly.

That is the same relationship this issue describes between a record and the process it names. A recorded value that is never compared, a pid signalled without attribution, and a refusal that cannot say which of two conditions produced it are all cases where something reads as verified without a check behind it. Worth adding as a general note: a guard and its test can be wrong in the same direction when one author writes both, because the reasoning that produced the guard is the reasoning that produces the test for it. The mutation is what separates them, and only if it is required to redden a named assertion rather than merely to turn something red.

[davidfarah2003]

A call-site census for localProcessOwnerStatus, since the issue named the function without measuring how far its answer travels. Measured independently in two trees.

The function reads two of the four fields it is given. ProcessOwner carries { pid, host, startedAt, id }; maintenance.ts:731 consults host for a guard and pid for the probe, and returns alive on a successful kill(pid, 0) or on EPERM. So alive means an integer is currently held by some process, not that the recorded process is still running, and the recorded startedAt that would settle the question is sitting unread in the same argument.

Thirteen shipped call sites, smoke files excluded:

packages/workspace/src/maintenance.ts:731   definition
packages/workspace/src/maintenance.ts:808   (options.ownerStatus ?? localProcessOwnerStatus)(stale.owner)
packages/workspace/src/maintenance.ts:844   (options.ownerStatus ?? localProcessOwnerStatus)(existing.owner)
packages/workspace/src/maintenance.ts:1140  localProcessOwnerStatus(proof.processOwner)
packages/workspace/src/maintenance.ts:2028  options.ownerStatus ?? localProcessOwnerStatus
packages/workspace/src/maintenance.ts:2227  (...)(record.listenerProof.processOwner)
packages/workspace/src/maintenance.ts:2435  options.ownerStatus ?? localProcessOwnerStatus
packages/workspace/src/maintenance.ts:2749  (...)(record.listenerProof.processOwner)
implementations/cli/src/commands/up.ts:82    import
implementations/cli/src/commands/up.ts:279   localProcessOwnerStatus(journal.listenerProof.processOwner)
implementations/cli/src/commands/up.ts:349   localProcessOwnerStatus(recoveredProof.processOwner)
implementations/cli/src/commands/up.ts:596   localProcessOwnerStatus(restoredAttempt.listenerProof.processOwner)
implementations/cli/src/commands/up.ts:1074  localProcessOwnerStatus(maintenance.listenerProof.processOwner)

Re-derive with:

grep -rn 'localProcessOwnerStatus\|ownerStatus ??' --include='*.ts' packages implementations \
  | grep -v node_modules | grep -v '/dist/' | grep -v smoke

The four up.ts call sites are given at main. The same census taken on the branch behind #880 reports them at 283, 353, 600 and 1074, because that branch adds four lines earlier in the file. The maintenance.ts positions are identical in both. Worth stating because a reader who checks these against the wrong tree will find three of them off by four and reasonably conclude the census is careless.

Two of the sites are worth separating from the rest. maintenance.ts:808 and :844 reach the function through options.ownerStatus ?? localProcessOwnerStatus, so the unverified answer is the default that ships whenever a caller supplies nothing, rather than something a caller opts into.

This also sharpens the asymmetry the issue describes rather than adding rows to it. processStartToken is consumed only by lock and mutation coordination, and every one of those consumers compares the recorded token against the live process. localProcessOwnerStatus is what the stop and recovery paths call, it is handed a record containing the same kind of token, and it never compares it. The verification exists, and it is wired to the paths that coordinate rather than the paths that destroy.

[davidfarah2003]

Three additions from a design pass on the Windows launcher, plus one correction to the scope of this issue's Windows half.

A fifth surface, and the sharpest one because it is not Windows-specific

implementations/cli/src/commands/down.ts:322-335 escalates a stop by re-probing and then signalling, entirely by pid, after whatever check preceded it:

while (probeLiveness(pid) !== "dead" && Date.now() < graceDeadline) await sleep(100);
if (probeLiveness(pid) !== "dead") { try { process.kill(pid, "SIGKILL"); } catch { } }

A recycled pid reads as alive, keeps the loop waiting out its grace window, and then takes a SIGKILL. The loop's own comment reads "Wait for CONFIRMED death (ESRCH), escalating to SIGKILL ... never deleted on a guess". It is scrupulous about not deleting a record on unconfirmed death and indifferent to which process it kills. It verifies the wrong end of its own operation.

This matters beyond adding a row. It shows that a recorded start token alone does not fix the class, because this path re-looks-up the pid after every check it makes. Any fix that verifies and then signals through a second lookup is a convention rather than a guard.

Two refinements to the suggested fix shape

Both come from a review pass that examined the Windows launcher across several independent readers, and both change what the primitive has to be rather than merely where it is called.

Compare-then-signal is not sufficient, because it reopens the window it just closed. Verifying a creation time and then calling process.kill(pid, ...) performs a second pid lookup after the comparison, so the pid can recycle in between. The terminate has to consume the very handle whose identity just matched: one operation that opens the process, reads its creation time, compares, terminates through that same handle, waits on that same handle, and closes it. A split into verify-then-signal is exactly the shape this issue is about.

The token has to be a required parameter of the signal seam, with no tokenless overload. If a bare-pid entry point remains callable, the guard is a rule people must remember rather than a property of the code. Making the unverified call impossible to write is the difference between this being fixed and being documented.

Correcting the scope of the Windows half

Two rows in the table above cite implementations/cli/src/lib/detached-spawn.ts on an unmerged branch. That caveat is already stated, but it understates the situation in a way worth being exact about: that file does not exist on main at all, and spawnDetached appears zero times in main's up.ts, which launches its detached broker with Node's own spawn(bin, args, { detached: true, ... }) and therefore keeps a real ChildProcess.

So the Windows identity gap is not a pre-existing defect that a pending change happens to touch. It arrives with that change. That is a different and higher bar for the change itself, and it slightly narrows this issue: the pidfile paths stand on main today, the Windows handle describes code that is not on main yet and would lapse entirely if that branch never lands.

The through-line, restated

Three separate surfaces have now converged on the same remedy shape: make the wrong call impossible to write rather than discouraged. A recorded start time that nothing compares, a pid signalled through a seam that accepts a bare pid, and a poll loop that re-resolves its target after checking it are all cases where the correct behaviour depends on a caller remembering something. The fix in each case is to remove the option, not to document the preference.

[davidfarah2003]

Confirmed at exact main SHA ae59d04d362bd76c5f5484b4f0673620a2db04b4 by exact-source proof. Current generic/auth/delivery pidfile stops parse a recorded PID, probe kill(pid,0), then send SIGTERM and possibly SIGKILL without comparing an OS process-start identity; manager adds POSIX argv attribution but still lacks same-process binding. Positive control: advisory-lock.ts already records and compares processStartToken (/proc/<pid>/stat field 22 or macOS lstart) and treats mismatch as recycled. ProcessOwner.startedAt is only application wall-clock metadata compared record-to-record, never against the live process. Ownership overlaps: PR #1057 explicitly closes #909 but says do not merge and permits legacy pid-only signals; PR #1069 owns the stronger identity-pin/fail-loud design under overlapping #969, but is merge-conflicted and lacks native Windows proof. Recommend bug, triage:confirmed, area:release, severity:critical, triage:owned. Do not duplicate. Orchestrator should consolidate the two owners, require native Windows identity proof, and separately disposition the maintenance/root residuals.

[davidfarah2003]

Reproduction attempt against main at ffa1501748d59d45234c1208a3322fbf14ceadd9. Summary: the central claim of this issue no longer holds at that base, and most of what it describes has been fixed by #969. One part still reproduces, and it turns out to be a different defect with a different lifetime, now filed separately as #1437.

Below, "RAN" means the line was executed and the result observed; "READ" means the code was inspected but not executed. The distinction is load-bearing here and is kept explicit throughout.

RAN

Two cells, each driving the real stopLocalProcess against a real child process with a real pidfile under an isolated temporary root.

Cell A — a record with no identity pin. verifyIdentityPin returned legacy. The stop path logged predates process identity pinning; signalling it without an identity check, sent SIGTERM to the recorded pid, and the uninvolved process — pid 1478536, which had nothing to do with the record — died. The call returned success, having printed ✓ stopped. This reproduces.

Cell B — a record whose pin names a different process start. verifyIdentityPin returned mismatch. The stop path refused with the pid has been reused (recorded start …, the live process …) and the process survived. This does not reproduce.

The divergence between record and live process is constructed in both cells rather than waited for, because kernel pid recycling cannot be forced on demand. What is under test is whether the stop path can detect the divergence, not whether the kernel produces it — the same construction packages/workspace/smoke/pid-identity.smoke.ts uses.

READ

The premise of this issue — "nowhere in the repo is it ever compared against the live process" — is no longer accurate. #969 introduced a sibling <pidfile>.identity pin and one shared open-verify-terminate rule, and four of the five signalling surfaces named here now run it before signalling:

Surface	Identity check
implementations/cli/src/commands/down.ts:320-323 (stopLocalProcess, the generic stop behind cotal down <component>)	verifyIdentityPin, mismatch refuses
implementations/cli/src/lib/auth-proc.ts:231 (stopAuthService)	same
implementations/cli/src/lib/manager-proc.ts:359 (stopManager)	same
implementations/cli/src/lib/delivery-proc.ts:288 (stopDelivery)	same

The write side matches: every launch site now pins — auth-proc.ts:177, up.ts:1005, up.ts:2110, up.ts:2133, delivery-proc.ts:153, manager-proc.ts:203.

Also READ, and unchanged:

• implementations/cli/src/lib/isolated-broker.ts:380 (stopByPid) still signals with only an alive() check and no identity verification. It is a non-exported closure fed by the watchdog handshake file and is not reachable from cotal down. It was deliberately not exercised: reaching it requires starting a broker. Carried into Windows records are never identity-pinned, so every Windows teardown permanently signals an unverified pid #1437 as unverified rather than asserted here.
• implementations/cli/src/commands/down.ts:382 still compares by raw === (mesh.root === root) in preserveStateDown, bypassing meshesForRoot (packages/workspace/src/mesh-registry.ts:276). Consequence is misidentification, not a signal — a recorded mesh reads as absent and the recovery verb refuses — so it is a different severity from the teardown rows and is not part of what reproduces above.
• implementations/cli/src/lib/detached-spawn.ts does not exist at this base. The two Windows-handle rows in the table above cited origin/feat/up-daemonize-persist, and this issue anticipated that they "will move with it and lapse entirely if it never lands". They have lapsed. Nothing in the current tree corresponds to them.

What remains, and where it now lives

Cell A is the only behaviour that still reproduces, and on closer reading it is not residue of this issue. The legacy branch exists for upgrade compatibility, justified by the assumption that an unpinned record ages out — the warning itself says "A relaunch will pin the process identity."

On Windows that never happens. defaultStartToken returns undefined there (packages/workspace/src/pid.ts:185-192), so identityRecord yields a token-less record (pid.ts:199-202) and writeIdentityPin writes no pin at all (pid.ts:284). Every Windows record therefore sits permanently in Cell A's state: probed for liveness, signalled without an identity check. That is a permanent platform gap rather than a transitional one, the upgrade-compatibility rationale does not reach it, and it deserves its own tracking. Filed as #1437, which also carries the isolated-broker.ts:380 row.

That behaviour was not changed here. Making an unpinned record refuse would break teardown on every Windows host until a win32 token mechanism exists, and this issue explicitly declines to settle that tradeoff ("the win32 question is open"). It is a product decision, not a cleanup.

Suggested disposition

Narrow this issue to the win32 policy question and the two rows that survive, or close it in favour of #1437, which states the remaining gap precisely and marks the parts that are unverified as unverified. The pidfile teardown class this issue argued for — one shared identity contract consumed by every stop path — was implemented by #969, and on Linux and macOS it demonstrably refuses the case this issue was filed about.

[davidfarah2003]

Closing as superseded by #1437. The fix pass at ffa1501 found the central claim no longer holds: every CLI stop path verifies the identity pin since #969. The one behaviour that still reproduces is the Windows unpinned steady state, which #1437 states precisely.