fix(server): archiving a thread stops only its own agent-browser daemon, over its socket

[immakermatty]

Status: ready for review

Problem

Archiving or deleting a thread stops its agent-browser daemon so the thread's tabs can end (F47 point 5, task 501). The overlay sent SIGTERM to the process the thread's .pid named, after checking that /proc/<pid>/cmdline was agent-browser's. A stale t3-<a>.pid whose number another session's agent-browser daemon has now would stop that daemon and could release its tab. The check and the signal also race. Pablo found the same path in Lazurio/LazurioPlatform#348 (lazurio browser done); this is the overlay's copy.

Fix

• stopSessionDaemon (in apps/server/src/lazurio/holders.ts) sends agent-browser's own graceful shutdown, {"action":"__agent_browser_internal_shutdown"}, on the session's own socket <socket dir>/t3-<thread>.sock. agent-browser's CLI sends the same in request_graceful_daemon_shutdown before it restarts a daemon. It then waits up to 5 s for the .pid to go. The daemon of an attached browser disconnects without closing a tab and removes its .pid, so the binding stops counting for the hub. No process id is signalled.
• Outcomes: stopped only once the .pid is gone; none when nothing listens on the socket (no daemon, or a stale socket file); refused when the daemon answers that it did not shut down; unconfirmed when no answer came after the command went out or the .pid is still there after 5 s, so the daemon may still hold the tab. threadTabs.ts logs thread-tabs-daemon-stop-failed with the outcome for the last two, replacing thread-tabs-daemon-not-agent-browser.
• The fork runbook's "Archivace a smazání" says so.

Not changed

• Which threads' daemons stop (archive, delete, and threads no longer live at start), the holder file removal, and every name outside t3-.
• agent-browser close is still never called, because it starts a daemon first when none runs.

Verification

• vp test run src/lazurio/holders.test.ts src/lazurio/threadTabs.test.ts (apps/server): 53 passed.
  • A live process named agent-browser (a symlink to /bin/sleep) has the number a stale t3-a.pid names, and only t3-b's daemon listens: stopping t3-a answers none, t3-b hears nothing and the process stays alive.
  • A stale socket file answers none; refusal and no answer give failed.
  • t3-a's own daemon gets exactly one shutdown line, and its .pid goes.
  • In the archive scenario, a live agent-browser behind B's stale .pid is untouched.
• vp lint and vp fmt --check on the changed files: clean. The CI typecheck vp run --filter t3 typecheck: 0 errors. The first head failed it on globalTimers/globalDate; holders.ts now opts out like the other overlay files that run outside the Effect runtime.
• Not yet: an archive on the canary Environment with the next preview.

This should land before the stable 0.0.45-lazurio.8, which would otherwise ship the PID path.

Plan: DEV-6646 task 2026-10-12-702 (the Platform side is Lazurio/LazurioPlatform#348).

Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[agentrozjedemeai]

@immakermatty Exact-head review of be5e8e5 (base b122de4). The stale-PID cross-session regression, archive/delete/startup call paths, t3-only filter, and runbook look aligned; CI is green and review threads are clear. Two error-path regressions violate the stated outcomes:

1. apps/server/src/lazurio/holders.ts:421-425,457-464: fileExists turns every fs.access rejection into false. In an isolated Node 26 fixture, I wrote t3-a.pid, had ask() return success while changing its parent directory mode to 000, and stopSessionDaemon returned "stopped" while t3-a.pid was still present (fs.access rejected EACCES; restoring the directory proved the file persisted). This violates the completion rule that only a gone .pid counts as stopped. Treat ENOENT as gone; permission/IO errors must be unconfirmed (or throw so the caller logs a failure), not stopped. Add a regression test for inaccessible .pid/parent.

2. apps/server/src/lazurio/holders.ts:417: askDaemonSocket maps every pre-connect error to "absent". An isolated listening Unix server with its t3-a.sock mode set to 000 returned {kind:"absent"} while server.listening was true. EACCES is not "nothing listens"; surface it as unconfirmed/failure rather than "none", and cover that case. Reserve "absent" for ENOENT/ECONNREFUSED (and other proven absence).

The focused suite was not rerun locally: vp/dependencies are absent in this disposable checkout and host memory pressure is high. I verified the two paths with locked, isolated Node fixtures, inspected the diff, and confirmed the exact-head CI run 38264853671 succeeds. Please fix these outcomes on a new head and repeat exact-head checks before merge/release.

[agentrozjedemeai]

@immakermatty APPROVED on exact head 4988c8f (base/current main b122de4). Re-review of my be5e8e5 blockers: fileExists treats only ENOENT as gone and failed PID checks return unconfirmed; the socket maps only ENOENT/ECONNREFUSED/ENOTSOCK before connect to absent, with permission/other errors unconfirmed. I exercised the exact source in a locked isolated Node 26 fixture: a stale A PID naming a live agent-browser process with only B listening returned none, B heard nothing and the process survived; chmod-000 listening socket and inaccessible-but-existing PID both returned unconfirmed; refusal, no answer, gone PID and rejected traversal behaved as specified. I also traced archive/delete/startup sweep and t3-only selection and checked the runbook. git diff --check clean; current-main merge-tree clean; CI run 38268788945 is green on this SHA (format, server/web typecheck, overlay tests and builds). No unresolved threads or other reviewer requests. Native vp tests were not rerun in this disposable checkout because vp/dependencies are absent; focused source fixture and exact-head CI are the execution evidence. This approves the PR head, not a release or any future head.