Manage OpenClaw Daemon Services: CLI Commands Guide

Managing background services shouldn’t feel like a guessing game. If you have been working with OpenClaw for a while, you might have used the daemon command to keep things running. It is actually a legacy alias for the Gateway service management commands.

When you run openclaw daemon ..., it points to the exact same service control surface as the newer openclaw gateway ... commands. It is there to keep your existing scripts working while you transition to the updated syntax.

Usage

openclaw daemon status
openclaw daemon install
openclaw daemon start
openclaw daemon stop
openclaw daemon restart
openclaw daemon uninstall

Subcommands

• status: Use this to check if the service is installed and to probe the health of your Gateway.
• install: This sets up the service on your system using launchd, systemd, or schtasks.
• uninstall: This removes the service from your system.
• start: This kicks off the service.
• stop: This brings the service to a halt.
• restart: This stops and then starts the service again.

Common options

• status: --url, --token, --password, --timeout, --no-probe, --require-rpc, --deep, --json
• install: --port, --runtime <node|bun>, --token, --force, --json
• lifecycle (uninstall|start|stop|restart): --json

There are a few things you should keep in mind regarding how these commands handle authentication and environment settings:

The status command tries to resolve your configured auth SecretRefs to check connectivity. If a required secret is missing, daemon status --json will report an rpc.authWarning. You can bypass this by passing the --token or --password flags manually. If the probe is successful, the tool hides these warnings so you don’t deal with false positives.

If you are running on Linux with systemd, the status command checks for token drift by looking at both Environment= and EnvironmentFile= unit sources. It resolves gateway.auth.token SecretRefs by checking the service command environment first, then falling back to the process environment.

The token-drift check is smart enough to skip resolution if token auth isn’t actually active. This happens if you have set gateway.auth.mode to password, none, or trusted-proxy. It also skips if the mode is unset and a password is used instead of a token.

When you use install and your token is managed via a SecretRef, the command confirms the secret can be resolved. It won’t save the actual resolved token into the service environment metadata. If the secret cannot be resolved, the installation will fail to keep your setup secure. Also, if you have both a token and a password configured but haven’t explicitly set a mode, the installation will block until you pick one.

Prefer

You should use openclaw gateway for current docs and examples.

Need help getting your service running? Try the AI Setup Assistant.

Next steps

• Gateway Service Documentation
• CLI Configuration Guide