fix(service): do not auto-enable systemd service on install

[darrenzeng2025]

Summary

• Base branch target: master
• Problem: zeroclaw service install previously ran systemctl --user enable, causing the daemon to auto-start on every login/boot.
• Why it matters: This created port conflicts when users later tried to run zeroclaw daemon manually, and violated the expectation that "install" does not imply "auto-start".
• What changed: Removed the enable step from zeroclaw service install; the service remains installed but inactive until the user explicitly runs zeroclaw service start.
• What did not change: The start/stop/uninstall commands or any service-unit template content.

Label Snapshot

• Risk label: risk: low
• Scope labels: service
• Change type: bug
• Primary scope: service

Linked Issue

• Closes [Bug]: Daemon service auto-starts on boot, causes port conflict for manual runs #5628

Validation Evidence

cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo test

• Evidence provided: code review, logic trace
• Intentionally skipped: local cargo build could not be fully validated due to a pre-existing toolchain issue (libsqlite3-sys compilation failure on this host). The change is isolated to the service-install command path.

Compatibility / Migration

• Backward compatible? Yes (behavior change, not API break)
• Config/env changes? No
• Migration needed? No
• Note: Users who relied on auto-start after install will now need to run zeroclaw service start explicitly.

Human Verification

• Verified scenarios: Traced the install command flow to confirm enable is removed and start is unaffected.
• Edge cases checked: N/A
• What was not verified: Full cargo test run due to local libsqlite3-sys build failure.

Side Effects / Blast Radius

• Affected subsystems: zeroclaw service install behavior.
• Potential unintended effects: Users expecting auto-enable may notice the service is not active after install.
• Guardrails: The CLI already prints next-step guidance after install.

Rollback Plan

• Fast rollback: git revert the single commit on this branch.
• Feature flags: None.
• Observable failure symptoms: Users report the service is not enabled after install.

Risks and Mitigations

None.

[theonlyhennygod]

Hi @darrenzeng2025 — this is a service behavior change so we need more context. Please update to follow our PR template — specifically Summary, Validation Evidence, Compatibility/Migration (since this changes systemd behavior), and Rollback Plan. Thanks!

[JordanTheJet]

Reviewer Verdict: Needs author action

0.7.0 Relevance Check

• File crates/zeroclaw-runtime/src/service/mod.rs exists on master.
• Line systemctl --user enable zeroclaw.service still present at master line 752.
• PR is still relevant post-v0.7.0 refactor.

Comprehension Summary

Removes the systemctl --user enable zeroclaw.service call from install_linux_systemd so that zeroclaw service install no longer wires the daemon to start automatically on user login. Closes #5628 by addressing option (b) from the issue (install does not imply auto-start).

Security Assessment

service/mod.rs is security-sensitive (touches systemd unit installation, runs as user). The change strictly reduces surface area — removing one shell-out — so no new injection or privilege risk. No unit-template content changed.

Findings

[suggestion] Cross-platform inconsistency. This PR only removes auto-enable for systemd. Other init systems still auto-start at boot/login:

• OpenRC: install_linux_openrc still calls rc-update add zeroclaw default (line ~1282) — the OpenRC equivalent of systemctl enable.
• macOS: install_macos writes a plist with RunAtLoad=true and KeepAlive=true, so once service start runs launchctl load -w, it auto-launches at login.
• Windows: install_windows registers a scheduled task with /SC ONLOGON.

After this change, systemd users get "install ≠ auto-start", but OpenRC/macOS/Windows users still get auto-start. Either align the other paths with the new contract, or scope the PR title/body to clarify it is systemd-only by design.

[question] No path for users who want auto-start. start_linux for systemd only runs systemctl --user start, never enable (or enable --now). After this PR, there is no CLI flag (e.g., --enable) and no documented command for users who do want the service to come back after reboot. Issue #5628 explicitly listed this as an alternative ("requiring an explicit zeroclaw service start"), but did not foreclose offering an opt-in. Should service install --enable or a follow-up doc note be added?

[nit] PR body label mismatch. Body's "Label Snapshot" claims risk: low; the auto-applied label is risk: high. Update one or the other so reviewers can trust the snapshot.

[nit] Validation evidence. Body lists cargo fmt/clippy/test but acknowledges the local build was blocked by libsqlite3-sys. Acceptable for a one-line removal, but call out that none of the three commands actually executed to completion.

Rollback Story

Single-line revert; clean. No state migration. Acceptable.

[singlerider]

Comprehension Summary

Removes systemctl --user enable zeroclaw.service from install_linux_systemd so that zeroclaw service install no longer auto-starts the daemon on login. Blast radius: service install behavior, systemd path only. Closes #5628.

Template Issues

• Label mismatch: PR body claims risk: low; the applied label is risk: high. service/mod.rs is in the runtime crate — risk: high is correct. Update the Label Snapshot section.
• Validation evidence: Body lists cargo fmt/clippy/test but acknowledges the local build was blocked by libsqlite3-sys. State explicitly that none of the three commands ran to completion rather than listing them as run.

Security / Performance

Strictly reduces surface area — removes one shell-out. No new injection or privilege risk. No unit-template content changed.

[singlerider]

[blocking] This removes enable for systemd only. Three other init paths still auto-start on install:

• install_linux_openrc calls rc-update add zeroclaw default — the OpenRC equivalent of systemctl enable
• install_macos writes a plist with RunAtLoad=true + KeepAlive=true
• install_windows registers a scheduled task with /SC ONLOGON

After this change, systemd users get "install ≠ auto-start" while all other platforms still auto-start. Either align the other init paths to the same contract or explicitly scope this PR as systemd-only in the title, body, and a code comment here.

[question] There is no CLI path for users who want the service to survive a reboot. start_linux_systemd only runs systemctl --user start, never enable. Consider adding zeroclaw service install --enable (opt-in) or at minimum documenting the manual workaround (systemctl --user enable zeroclaw.service) in the post-install output.