service

name	service
description	Run the agent as an always-on background service (launchd on macOS, systemd on Linux). Triggers on /agent:service, /agent:service install, /agent:service status, /agent:service uninstall, /agent:service logs, "always-on", "background service", "correr 24/7", "run as daemon", "launchd", "systemd".
user-invocable	true
argument-hint	install|status|uninstall|logs

Always-on service

Wrap Claude Code (with ClawCode) in the OS's service manager so the agent keeps running after the terminal closes. This is what makes the HTTP bridge, WebChat, webhooks, and crons work 24/7.

This is an OPTIONAL feature. See docs/service.md for the full reference, risks, and how to add messaging-channel flags.

⚠️ Safety — read before install

Installing the service runs Claude Code with --dangerously-skip-permissions in the background. That flag:

• Pre-approves every tool call (Bash, Write, Edit, network requests)
• Cannot be undone per-request — the running service has full permissions over the agent's workspace for its whole lifetime
• Is necessary because a daemon cannot answer interactive tool-approval prompts

This is an irrevocable trust decision for this workspace. Only run /agent:service install if you understand that.

Always prompt the user to confirm before installing. Quote the flag by name in the confirmation. If the user hesitates or asks questions, stop and explain.

Dispatch

Parse the action and call service_plan with it.

User says	Action argument
/agent:service install	install
/agent:service status (or no arg)	status
/agent:service uninstall	uninstall
/agent:service logs	logs

Install flow

1. Find the claude binary: Bash(which claude). Trim output. If empty, abort with: "Can't find claude in PATH. Install Claude Code or point me at it manually."
2. Call service_plan({ action: "install", claudeBin: <path> })
3. If the plan has error (unsupported OS), print the error and stop.
4. Show the user the warning (see Safety section). Ask explicitly: "This will install a background service that runs with --dangerously-skip-permissions. Confirm? [y/N]"
5. If the user says no, stop with a neutral acknowledgement.
6. If the user confirms:
   • Pre-check ~/.claude/settings.json (prevents the most common install hang — see docs/service.md "Heads-up" note):
     • Read the file with Read(~/.claude/settings.json). If it doesn't exist or is empty, treat as {}.
     • If skipDangerousModePermissionPrompt is already true, skip to the next sub-step.
     • Otherwise, tell the user: "Heads-up: your ~/.claude/settings.json is missing \"skipDangerousModePermissionPrompt\": true. Without it, the service will show a 'Bypass Permissions — Do you accept?' dialog at startup that no daemon (launchd / systemd) can answer, and the install will appear to succeed but the service will hang silently. Add it now? [y/N]"
     • If yes: merge with jq via Bash (preserves any other keys, atomic write): Bash: jq '. + {"skipDangerousModePermissionPrompt": true}' ~/.claude/settings.json > ~/.claude/settings.json.tmp && mv ~/.claude/settings.json.tmp ~/.claude/settings.json (If the file did not exist, first run Bash: echo '{}' > ~/.claude/settings.json so jq has something to merge into.) Confirm with one line: "Added skipDangerousModePermissionPrompt: true to ~/.claude/settings.json."
     • If no: warn explicitly "Without it the service will hang at startup. Continue anyway? [y/N]". On a second no, abort with a neutral acknowledgement and do not write any service files. On yes, proceed and let the user deal with it.
   • If plan.extraFiles is present, for each entry: ensure the parent dir exists (Bash(mkdir -p <dirname>)), then Write(file.path, file.content), then Bash(chmod <octal> <file.path>) using file.mode (default 0o644 when omitted). These are auxiliary scripts the unit file needs to exist before start — e.g. the resume-on-restart wrapper.
   • Write the plist / unit file: Write(filePath, fileContent) — the plan tells you the path
   • Run each command from plan.commands in order with Bash, printing the label before each
   • If any command fails, stop and report the error (do NOT try to roll back — the user can run uninstall to clean up)
7. Final line: "Service installed. Label: <plan.label>. Log: <plan.logPath>. Run /agent:service status to verify."

Status flow

1. Call service_plan({ action: "status" })
2. Run each command from plan.commands with Bash
3. Summarize in one line: "Active" / "Not loaded" / "Unknown" based on the command output

Uninstall flow

1. Call service_plan({ action: "uninstall" })
2. Ask the user: "Remove the <plan.label> service? [y/N]"
3. On confirmation, run each command from plan.commands
4. Report: "Service removed."

Logs flow

1. Call service_plan({ action: "logs" })
2. Run the single tail command and print output directly.

Response style

• On CLI and WebChat: multi-line with labels.
• On messaging channels: compress to essentials. Command output can get long — if the log dump would exceed ~20 lines, just say "check /tmp/clawcode-<slug>.log directly" instead.

Never

• Never install the service without the safety confirmation. If the user insists without reading the warning, say you need them to explicitly confirm the flag.
• Never run launchctl or systemctl commands that aren't in the plan returned by service_plan — the tool is the source of truth.
• Never modify the plist / unit file after creation from an imagined config. If the user wants to add channel flags, re-run /agent:service install with the updated flags (future: expose an extraArgs UX).

References

• docs/service.md — full doc, risks, channel-flag customization
• lib/service-generator.ts — pure generators
• docs/INDEX.md