How to Run OpenClaw Agents as Persistent Background Processes

TL;DR: OpenClaw’s gateway dies when you close your terminal because the process is attached to your shell session. The fix is to detach it using pm2 (Linux/Mac), nssm (Windows), or Task Scheduler. For scheduled agent runs, pair the background gateway with cron or webhook triggers. If you want to skip all of this, ClawTrust manages uptime and scheduling for you as a hosted service.

I spent an embarrassingly long time wondering why my OpenClaw agent stopped mid-run every time I closed my laptop. The gateway process was fine. The config was fine.

The problem was simpler: the gateway was still tied to my terminal session, and the moment that session closed, the whole thing went down.

This guide covers every method for keeping OpenClaw running in the background, scheduling agent runs, and monitoring what’s happening when you’re not watching.

Whether you’re on Linux, Mac, or Windows, there’s a setup here that works for your machine.

If you haven’t finished your initial setup guide, start there first. This guide assumes the gateway runs locally and you can access it at localhost:3741.

Why the OpenClaw Gateway Dies When You Close Your Terminal

The gateway dies because it’s a child process of your terminal session. When the session ends, the OS sends a hangup signal (SIGHUP) to every process in that session, and OpenClaw shuts down along with everything else.

This is standard Unix process behavior, not a bug. Every time you run openclaw gateway start in a terminal, that process inherits the lifecycle of the shell that launched it.

There are three ways this catches people:

1. You start the gateway, close your SSH session, and come back to a dead gateway.
2. You schedule an agent run for 2am, but the gateway isn’t alive at 2am because no one’s logged in.
3. You start a long-running agent task, switch to a different window, and lose the terminal tab.

The fix is to detach the gateway from your shell session so it survives independently. The tool you use depends on your OS and how much control you want.

Running OpenClaw Gateway in the Background with pm2

pm2 is the simplest persistent process manager for Linux and Mac. It starts OpenClaw’s gateway as a daemon, keeps it alive through crashes, and restarts it automatically after a reboot.

pm2 is the approach I use on my own machines. It’s a Node.js-native process manager with clean logging and a dashboard that tells you exactly what’s running.

According to npm, pm2 has over 300 million downloads, making it one of the most widely deployed process managers in the Node ecosystem.

Installing pm2

npm install -g pm2

Starting the OpenClaw Gateway with pm2

Here are the exact steps:

1. Install pm2 globally if you haven’t already: npm install -g pm2

2. Start the OpenClaw gateway as a named pm2 process:

   pm2 start "openclaw gateway start" --name openclaw-gateway

3. Save the current pm2 process list so it survives reboots:

   pm2 save

4. Generate a startup script so pm2 itself restarts after a reboot:

   pm2 startup

Follow the command it prints. It will look something like sudo env PATH=...

5. Confirm the gateway is running:

   pm2 status

6. Tail the logs to confirm OpenClaw is listening on port 3741:

   pm2 logs openclaw-gateway

After step 4, your gateway survives reboots, crash-restarts itself, and is completely decoupled from any terminal session.

Useful pm2 Commands for OpenClaw

pm2 restart openclaw-gateway    # restart after config changes
pm2 stop openclaw-gateway       # stop without removing from list
pm2 delete openclaw-gateway     # remove from pm2 entirely
pm2 monit                       # live dashboard for CPU/memory/logs

Running OpenClaw on Windows with nssm or Task Scheduler

On Windows, you have two solid options: nssm (Non-Sucking Service Manager) wraps OpenClaw as a Windows Service, or Task Scheduler can trigger the gateway at startup and run scheduled agent tasks.

Windows handles background processes differently. There’s no direct equivalent of nohup or pm2, but Windows Services and Task Scheduler cover the same ground once you know the right approach.

Option 1 – nssm (Recommended for Persistent Gateway)

nssm turns any executable into a Windows Service. This means OpenClaw’s gateway gets the same treatment as any system service: it starts on boot, restarts on failure, and runs with no terminal attached.

Download nssm from nssm.cc, then open an elevated command prompt:

nssm install OpenClawGateway

This opens a GUI where you set:

• Path: Full path to openclaw.cmd (e.g., C:\Users\YourName\AppData\Roaming\npm\openclaw.cmd)

• Arguments: gateway start

• Startup directory: Your OpenClaw config directory (usually C:\Users\YourName\.openclaw)

Then start the service:

nssm start OpenClawGateway

Check it in Services (Win+R, type services.msc). Look for “OpenClawGateway” with status “Running.”

Option 2 – Task Scheduler (Simpler, Less Control)

For lighter use cases, Task Scheduler works without any extra installs:

1. Open Task Scheduler (search for it in the Start menu)
2. Click “Create Basic Task”
3. Set the trigger to “When the computer starts”
4. Set the action to “Start a program”
5. Program: C:\Windows\System32\cmd.exe
6. Arguments: /c "openclaw gateway start"
7. Check “Run whether user is logged on or not”
8. Check “Run with highest privileges”

The nssm approach is cleaner for production use because it handles failure restarts. Task Scheduler is fine for low-stakes setups where occasional missed restarts are acceptable.

Background Process Options at a Glance

screen and nohup are worth knowing for quick testing, but I’d lean toward pm2 or nssm for anything you want reliably running week after week.

Scheduling Agent Runs with Cron

Cron lets you trigger OpenClaw agent tasks at specific times without keeping a terminal open. The gateway handles each run, and cron fires the CLI trigger on your schedule.

This works on Linux and Mac. The gateway must already be running as a background process (pm2 is the natural pairing here) before cron can send it work.

Cron Syntax Reference

Setting Up a Cron Job for OpenClaw

Open your crontab:

crontab -e

Add a line like this to trigger an OpenClaw agent run at 2am every day:

0 2 * * * /usr/local/bin/openclaw agent run --config /home/youruser/.openclaw/openclaw.json >> /home/youruser/.openclaw/logs/cron.log 2>&1

A few things to note here:

• Use absolute paths for both the openclaw binary and the config file. Cron runs with a minimal environment and won’t find commands via your PATH shortcut.

• The >> redirect appends output to a log file so you can review what ran. The 2>&1 captures errors too.

• Confirm the cron job is registered: crontab -l

For Windows, the equivalent is a Scheduled Task with a “Daily” trigger pointing to the openclaw CLI.

Using Webhooks to Trigger Agent Runs on Events

Webhooks let external systems fire OpenClaw agent runs the moment something happens, without polling or fixed schedules. The gateway’s built-in webhook listener receives a POST request and runs the configured agent.

The OpenClaw gateway exposes a webhook endpoint at http://localhost:3741/webhook by default. Any system that can send an HTTP POST can trigger a run.

Webhook Trigger Example

Here’s an example using curl to fire a run manually (good for testing):

curl -X POST http://localhost:3741/webhook \
  -H "Content-Type: application/json" \
  -d '{"agent": "my-agent-name", "payload": {"source": "manual-test"}}'

In production, replace localhost:3741 with your server’s public IP or domain if you’ve exposed the gateway externally. Always place a reverse proxy (nginx or Caddy) in front of it with auth headers before exposing to the internet.

Webhook triggers work well for:

• Running a research agent when a new form submission arrives

• Firing a content agent when a GitHub push completes

• Triggering a notification agent when a monitoring threshold is hit

Monitoring Background Agent Runs

Check pm2 logs, OpenClaw’s own log files, and the gateway healthcheck endpoint to confirm your background agents are running and not failing silently.

Silent failures are the biggest risk with background agents. Everything looks fine until you check the output and realize nothing ran for the past three days.

pm2 Monitoring

pm2 status                          # quick status table
pm2 logs openclaw-gateway           # live log tail
pm2 logs openclaw-gateway --lines 200  # last 200 lines
pm2 monit                           # live CPU/memory dashboard

OpenClaw Log Files

Logs land in ~/.openclaw/logs/ by default. The location is controlled by the logLevel and logPath fields in ~/.openclaw/openclaw.json.

{
  "gatewayPort": 3741,
  "resetTime": "03:00",
  "logLevel": "info",
  "logPath": "/home/youruser/.openclaw/logs"
}

Setting logLevel to "debug" gives you verbose output that includes every agent step, which is useful when you’re first confirming background runs are working.

Gateway Healthcheck Endpoint

The gateway exposes a healthcheck at:

GET http://localhost:3741/health

A healthy response returns {"status": "ok"}. You can hit this from a monitoring service (UptimeRobot, BetterStack, etc.) to get alerts when the gateway goes down.

If you hit issues keeping the gateway alive or spot errors during startup, the common OpenClaw errors guide covers gateway auth failures, port conflicts, and startup crashes in detail.

ClawTrust – Hosted OpenClaw With Uptime Managed for You

If you don’t want to manage pm2, configure nssm, or debug cron jobs at 2am, ClawTrust is a managed OpenClaw hosting service that keeps the gateway running and handles scheduling through a web interface.

Setting up pm2 is genuinely not hard, but keeping a self-hosted gateway reliable over weeks and months does require ongoing attention.

Security patches, server reboots, disk space, dependency updates, and the occasional crashed process that pm2 misses all add up to real maintenance time.

ClawTrust removes that entirely. Your gateway runs on their infrastructure, uptime is their problem, and you configure scheduled agent runs from a dashboard instead of editing crontabs.

For anyone running OpenClaw for a side project or client work rather than as a full-time engineering focus, the time savings are worth more than the cost.

It also solves the single biggest pain point for remote or webhook-triggered runs: your local machine doesn’t need to be on.

The gateway is always reachable from any trigger source, regardless of what your laptop is doing.

For more on getting the most out of your setup financially, see the guide on managing OpenClaw API costs and persistent memory configuration.

Frequently Asked Questions

Short answers to the most common questions about running OpenClaw in the background.

Does OpenClaw have a native background mode?

No. The gateway itself doesn’t have a built-in daemon flag. You need an external process manager (pm2, nssm, or a system service) to detach it from your terminal session. The OpenClaw team has discussed adding a --daemon flag in a future release, but it’s not available as of March 2026.

Can I run multiple OpenClaw gateways on the same machine?

Yes, but each instance needs a different port. Change gatewayPort in each instance’s openclaw.json and pass the correct config path when starting each gateway. pm2 supports multiple named processes pointing to different configs.

What happens if the gateway crashes mid-run?

If you’re using pm2, it restarts the gateway automatically within a few seconds. Any agent run that was in progress when the crash occurred will not resume. OpenClaw does not have built-in checkpoint/resume for in-flight runs. Designing agents to be idempotent (safe to re-run from scratch) is the practical workaround here.

Is the webhook endpoint secure by default?

No. The webhook endpoint at localhost:3741/webhook has no authentication in the default config. If you’re exposing it to the internet, put nginx or Caddy in front of it with an API key header check before going live.

How do I set a daily reset time for the gateway?

Set the resetTime field in ~/.openclaw/openclaw.json. The value is a 24-hour time string. For example, "resetTime": "04:00" resets the gateway at 4am, which is useful for clearing long-running agent state on a daily cycle.

Can ClawTrust replace my self-hosted setup completely?

For most use cases, yes. ClawTrust supports the same OpenClaw config file format, so migration is straightforward. Upload your openclaw.json, connect your API keys, and set your schedule in their dashboard. The only gap is if you have custom integrations that require the gateway to be on your local network.