Skip to content

docs(systemd): document baked-in PATH directive and user-level security framing#17

Merged
Aaronontheweb merged 1 commit into
netclaw-dev:devfrom
Aaronontheweb:docs/systemd-path-and-security-framing
May 9, 2026
Merged

docs(systemd): document baked-in PATH directive and user-level security framing#17
Aaronontheweb merged 1 commit into
netclaw-dev:devfrom
Aaronontheweb:docs/systemd-path-and-security-framing

Conversation

@Aaronontheweb
Copy link
Copy Markdown
Contributor

Summary

Companion docs PR for the daemon-install fix in netclaw-dev/netclaw#948, which bakes `Environment=PATH=` into the generated systemd user unit so the agent's shell tool can resolve `netclaw` and other user-installed binaries.

Changes

`src/content/docs/deployment/systemd.md`

  • New Why user-level systemd? section, framing the choice as security-neutral relative to running the daemon directly from your shell. Same files, same credentials, same network endpoints reachable; what systemd buys you is operational reliability (auto-restart, lingering, journal integration) without elevated privileges. The contrast that matters is user-level vs. system-level — and Netclaw's threat model has no use for either root or a dedicated service identity.
  • Both unit-file examples (auto-generated and manual) now include `Environment=PATH=`, with a paragraph explaining why systemd's sanitized default PATH would otherwise break shell-tool invocations from inside the daemon.
  • New troubleshooting entry: Shell tool can't find `netclaw` (or other user-installed binaries) — for users upgrading from a version before the PATH directive was baked in, with uninstall+install migration and a `/proc` verification command.

`src/content/docs/cli/overview.md`

  • `daemon install` and `daemon uninstall` rows in the Daemon Management table now link to the systemd deployment page (matching the linking convention used in the other tables).
  • One-sentence note under the table summarizing the user-level model and pointing readers at the security framing.

Test plan

  • Render preview and visually check the "Why user-level systemd?" section heading anchor and table-of-contents inclusion
  • Verify the cross-link from the unit-file PATH explanation to the new troubleshooting anchor (`#shell-tool-cant-find-netclaw-or-other-user-installed-binaries`) resolves
  • Verify both `/deployment/systemd/` and `/deployment/systemd/#uninstalling` links from `cli/overview.md` resolve

The netclaw daemon install command now bakes Environment=PATH= into
the generated systemd user unit so the agent's shell tool can resolve
netclaw and other user-installed binaries (netclaw-dev/netclaw#948).
Update the systemd deployment doc to match:

- Add a "Why user-level systemd?" section that frames the choice as
  security-neutral relative to running the daemon from the shell —
  same privileges, same blast radius, plus operational reliability.
  The contrast that matters is user-level vs. system-level.
- Update both unit-file examples (auto-generated and manual) with
  the Environment=PATH= line and explain why it's needed.
- Add a troubleshooting entry for "shell tool can't find netclaw"
  on upgraded installs that still have the older unit file, with
  uninstall+install migration steps and a /proc verification command.

Also surface the security framing one click away from where users
encounter the install command:

- Make the daemon install/uninstall rows in cli/overview.md link
  to the systemd page.
- Add a one-line note under the Daemon Management table summarizing
  the user-level model.
@Aaronontheweb Aaronontheweb merged commit b21ea9a into netclaw-dev:dev May 9, 2026
2 checks passed
@Aaronontheweb Aaronontheweb deleted the docs/systemd-path-and-security-framing branch May 9, 2026 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant