[roodboi]

Follow-up to #709/#745 (HACK-2052): hack daemon stop decides which Hack home the running daemon serves from the process itself, not from the loaded unit configuration, and leaves another home's daemon alone only on positive evidence.

Why

stop read the unit's Hack home from systemd's loaded configuration. Suppose a drop-in that set another Hack home is removed and the manager is reloaded without a restart. The configuration then says "this home" while the running daemon still serves the other one, so stop from the default home stopped the other home's daemon.

What changes

flowchart TD
  A[hack daemon stop] --> Q{unit state and MainPID read?}
  Q -- query failed --> R[refuse with systemctl --user status / stop steps]
  Q -- yes --> B{live MainPID?}
  B -- no, e.g. pending restart --> D{loaded config's Hack home}
  B -- yes --> C[prove: hackd image holding a socket in this home's daemon dir, identity stable]
  C -- this home's --> H[recheck MainPID, then systemctl --user stop]
  C -- exited meanwhile --> D
  C -- unidentifiable or not hackd --> R
  C -- hackd without this home's socket --> F{config names another home H?}
  F -- no: this home or unreadable --> R
  F -- yes --> P[prove it holds a socket in H's daemon dir]
  P -- proven, or exited meanwhile --> N[leave the unit alone; stop this home's own hackd]
  P -- not proven: still starting or unreadable --> R
  D -- this home --> H
  D -- another home --> N
  D -- unreadable --> R

Loading

• Failed queries refuse. A unit-state or MainPID query that fails is not "no process". It refuses with the manual commands, whether or not the unit file is present. So does a final re-read that fails or finds the manager unavailable, also during a pending restart with no main process.
• Live main process: proven with proveOwnedDaemonProcess. The image may come from another install or checkout (a Bun launcher, the dev shim), because systemd names the process; the socket proves the home. A launcher main process counts when this home's proven hackd is its direct child in the unit's cgroup.
• Another home's daemon is left alone, and hack daemon stop/restart still stop this home's own hackd, only on positive evidence: the configuration names another home, and the process is proven to hold a socket in that home's daemon directory (or exited while being checked). A hackd holding neither home's socket is refused with "may still be starting: run hack daemon stop again", or with the manual steps if its sockets cannot be read.
• No live process (a pending restart): the configuration decides, so stop still cancels the restart.
• No unit file at the managed path: another home's configuration is left alone when nothing runs, the main process exited meanwhile, or the process is proven another home's. Anything else is refused, because without the file it cannot be checked.
• Just before systemctl --user stop, the unit's state is read again, and a changed main pid or a failed read is refused. This narrows the gap without closing it: a change after that read, or a reused pid, is not detected.
• Hosted Linux check of the CLI install flows: the Linux-only linux-process-lifetime job removes group/other write under the runner's /usr and /opt, and gives root the files owned by other regular accounts (uid at or above UID_MIN). It then runs tests/daemon-systemd-cli.test.ts with HACK_TEST_REQUIRE_INSTALL_FLOWS=1, so the real protected-directory decision runs on hosted Linux and a refusal fails instead of skipping. The job is not itself a required check, but whenever it is selected the test fan-in job (from next) fails if it fails or is skipped unexpectedly.

Evidence (local, Linux)

• New tests, each failing without its fix:
  • The reload case: a drop-in removed and reloaded without a restart, with the daemon still serving the other home, is refused.
  • Unreadable process evidence is refused, this home's daemon is stopped, and a pending restart is cancelled.
  • A live daemon of another home is left alone, not refused: this holds for a drop-in, the manager environment, UnsetEnvironment and the account's home, with and without the unit file. A hackd holding neither home's socket is refused with the retry hint, and one that exits during the proof is left to its home.
  • A failed state query, or a failed final re-read, refuses even when the configuration names this home.
  • A main process that changes while it is checked is refused.
  • Another install: this home's daemon run by another install is accepted through the real proof (a live child stands in as MainPID). A non-hackd image is refused, and a hackd that has not bound its socket gets the "may still be starting" message.
• The daemon, CLI-flow and process-proof tests pass. bun run typecheck, bun run check, bun run privacy:check and gitleaks are clean.

🤖 Generated with Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
hack-docs	Ready	Preview	Nov 13, 2026 11:11am UTC

[roodboi]

@codex review

[linear-code]

HACK-2052

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-13T11:13:33.992558Z	ea68836	Manual request
🔒 Security Review	✅ Completed 2026-11-13T11:16:37.151070Z	ea68836	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cd24d822f9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: cd24d822f9

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[roodboi]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Chef's kiss.

Reviewed commit: a026d2339a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: a026d2339a

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[roodboi]

Ready for lead: head 611cea7011759ce1fb4d5c4dd9a4c13079d2b7d1

Review: the persistent reviewer is clean at 611cea7 (round 6; rounds 1 to 5 were fixed). computer pr review-status: CLEAR at 611cea7011, with no bot threads or change requests. Codex last reviewed an earlier head; the commits since then change only CI (.github/workflows/ci.yml), and I requested a re-review below.

Linux gates green at this head:

• Config compiler (ubuntu-latest, ubuntu-24.04-arm): typecheck and lint.
• test shards 4 to 8.
• linux-process-lifetime, including the new "Harden runner system trees for the daemon install flows" and "Run daemon install flows" steps. HACK_TEST_REQUIRE_INSTALL_FLOWS=1 is set there, so the CLI flows cannot skip.
• Candidate core (ubuntu), Change scope, test focus, Runtime state models, secret-scan, runtime-images and docs site.

Still pending: Candidate core (macos-latest), Config compiler (macos-latest, macos-15-intel), test shards 1 to 3 (macOS) and docker-e2e shards 1 to 4.

What it does: hack daemon stop proves which Hack home the running daemon serves from the process itself: its image, its socket in the daemon root, and an unchanged start time. When the unit's main process is a launcher, the hackd must be its direct child and inside the unit's cgroup. When the home differs or can't be proven, stop refuses and prints the manual systemctl --user status/stop steps. Same-home stop, and cancelling a pending restart, still work. Tests cover:

• a drop-in removed and reloaded without a restart;
• process evidence that can't be read;
• a foreign install, through the real proof;
• the launcher case, including a parent mismatch;
• the same-home success.

The protected-directory decision is checked again by a hosted Linux CLI flow. The runner-hardening step removes group/other write under /usr and /opt. It gives root only files owned by other regular accounts (uid at or above UID_MIN), so system accounts' files keep their owner and setuid bits.

HACK-2070 (fresh-host qualification), what it needs from the owner:

• A disposable Ubuntu 24.04 VM with a sudo-capable user and its own Docker engine, so nothing on it is shared with other work.
• The owner types sudo for the three privileged steps: the resolver drop-in, system CA trust, and the reboot.
• I do the rest: clean install, hack setup, the daemon service, DNS and trust checks. I then verify again after the owner logs out and back in and after the reboot, with the evidence recorded on HACK-2070.
• Nothing in this PR substitutes for that run: hosted CI does not qualify a fresh host.

🤖 Generated with Claude Code

[roodboi]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 611cea7011

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: 611cea7011

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[roodboi]

Update to the ready comment: Codex code review is clean at head 611cea7011 ("Didn't find any major issues"), and its automatic security review found nothing. The macOS and docker-e2e jobs are still running.

[roodboi]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Another round soon, please!

Reviewed commit: 1213425cbe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: 1213425cbe

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[roodboi]

Ready for lead: head 1213425cbe29caa913359a91fa5576365fe3943d

Your blocker is fixed: hack daemon stop no longer refuses when the unit runs another Hack home's daemon.

• checkMainProcessServesHome now separates two outcomes:

  • proven foreign: a hackd holding another home's socket;
  • refused: a process that can't be identified (unreadable, not hackd, or changed while checked).

• A new decideUnitStop combines that with the loaded configuration:

  Main process	Configuration names	Result
  this home's hackd	(not read)	stop
  unidentifiable	(not read)	refuse
  foreign hackd	another home	leave the unit alone; daemon.ts then stops this home's own hackd
  foreign hackd	this home (your drop-in/reload case)	refuse
  foreign hackd	unreadable	refuse
  none (pending restart)	another / this / unreadable	leave / stop / refuse, as before

• stopWithoutUnitFile leaves a unit loaded from another home's directory alone when nothing runs or its process is a proven foreign hackd. Anything else is still refused.

• New test "a live daemon of another Hack home is left alone, not refused". The unit has a live foreign main process, and the configuration names another home in each of four ways: a drop-in, the manager environment, UnsetEnvironment, and the account home. Each case gives {handled:false, ownedPid:false, failed:null, refused:null}, no systemctl stop, and the unit stays active. An unknown process is still refused. Without the unit file, foreign is left alone and unknown is refused. The test fails on 611cea7.

• Limit: no test runs daemon.ts directly, because it has no seams. The unit result is the contract: with refused null and ownedPid false, handleDaemonStop goes on to stop the pid in this home's pid file, through its ownership proof.

• docs/architecture.md is updated.

Your should-fix items:

1. Proof-to-stop gap: fixed here. The unit's status is read again just before systemctl --user stop, and a different MainPID (including one appearing or disappearing) is refused with "changed while it was being checked … run hack daemon stop again". It has its own test. The docs state the remaining window: the milliseconds between that read and the stop.
2. Type=simple start window: fixed here. A proven hackd without this home's socket under a configuration naming this home gets "It may still be starting: run hack daemon stop again in a moment", whether systemd reports it activating or already active. Tested for both states.
3. For the CI session: linux-process-lifetime is not a required check, and no fan-in job depends on it, so the new "Run daemon install flows" step (with HACK_TEST_REQUIRE_INSTALL_FLOWS=1) does not gate merges. I did not change branch rules.

Review: the persistent reviewer is clean at 1213425 (round 7). It also confirmed that the drop-in/reload case is still refused. Codex's code review of 1213425cbe found no major issues, and its automatic security review found none. computer pr review-status: CLEAR at 1213425cbe, 0 unresolved bot threads. The tool lists Codex as having reviewed an earlier commit, but Codex's own comment names 1213425cbe. next has moved, but only on files this PR doesn't touch.

Gates green at this head:

• Config compiler (ubuntu-latest, ubuntu-24.04-arm, macos-15-intel)
• Candidate core (ubuntu, macos)
• test shards 3 to 8
• linux-process-lifetime, including the install flows
• docker-e2e, all 4 shards
• Runtime state models, Change scope, test focus, secret-scan, runtime-images and docs site

Still pending: Config compiler (macos-latest) and test shards 1 to 2.

HACK-2070: unchanged from my earlier note. It needs a disposable Ubuntu 24.04 VM with a sudo user and its own Docker. The owner types sudo for the resolver drop-in, system CA trust and the reboot; I do the rest and verify after re-login and reboot.

🤖 Generated with Claude Code

[roodboi]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

Reviewed commit: 31f0201cf2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: 31f0201cf2

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[roodboi]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. 🎉

Reviewed commit: ea68836421

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review · Automatically triggered

Security review completed. No security issues were found in this pull request.

Reviewed commit: ea68836421

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.