# OpenClaw Guardian watches your agent gateway and rolls it back with git when it breaks

> openclaw-guardian is a shell watchdog for the OpenClaw Gateway that checks health every 30 seconds, runs openclaw doctor --fix up to three times, falls back to a git rollback, snapshots the workspace daily and can alert on Discord. It is a thin script built from a company's production setup.

**LeoYeAI/openclaw-guardian** — 🛡️ Guardian watchdog for OpenClaw Gateway — auto-monitor, self-repair via doctor --fix, git-based rollback, daily snapshots, and Discord alerts. Powered by MyClaw.ai

- Repository: https://github.com/LeoYeAI/openclaw-guardian
- Website: https://myclaw.ai
- Stars: 568 · Forks: 104
- Language: Shell
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/leoyeai-openclaw-guardian

## A watchdog for an agent that runs while you are asleep

openclaw-guardian is described as a guardian watchdog for the OpenClaw Gateway, with auto-monitor, self-repair via doctor --fix, git-based rollback, daily snapshots and Discord alerts, powered by MyClaw.ai.

The problem it addresses is specific to a new class of deployment. The README describes MyClaw.ai as an AI personal assistant platform that gives every user a fully-featured AI agent running on a dedicated server, with complete code control, internet access and tool integrations, and the project says it is an open-source project born from that production infrastructure, where thousands of AI agent instances run around the clock and Guardian is the hardening layer that keeps them alive.

So the threat model is not a malicious user. It is a long-running agent process that stops answering, or breaks itself while working, at three in the morning when nobody is watching. The watchdog exists to notice and to put the thing back the way it was.

That framing matters for how you read the rest of the project. Every feature is aimed at unattended recovery rather than at diagnosis. The repository is MIT licensed, the primary language is Shell, and the last push was on 2026-07-14, so this is a small set of scripts rather than a service with a runtime.

## The recovery ladder, in the order the script tries it

The How It Works section of the README draws the decision flow as a diagram, and the order is the interesting part. The flow starts at gateway down detected, drops into the doctor --fix repair stage with up to three attempts, and asks whether that succeeded. Success ends the process. If all the repair attempts fail, the flow drops into the git rollback stage, which also asks whether it succeeded. If the rollback fails too, the last stage is a cooldown of 300 seconds before monitoring resumes.


Three stages, escalating in destructiveness. First, the least invasive repair, running openclaw doctor --fix, retried up to three times. If the gateway is back, the script stops there and nothing else happened.

If every repair attempt fails, the second stage is a git rollback, which resets the workspace to the last stable commit. That is the destructive step. Whatever the agent changed since that commit is gone, and it is gone without asking.

If the rollback also fails, the third stage is a cooldown of 300 seconds before monitoring resumes. Nothing else is tried, and the script does not escalate further or give up permanently.

The ordering encodes a sensible cost model. Repair is cheap and reversible, rollback is destructive but bounded, and after a failed rollback the best thing to do is wait rather than loop. That said, note what is not in the chain. There is no alert before the rollback, no human approval step, and no record of which stage succeeded beyond the log.

## The rollback is only as good as your git history

The auto-rollback feature resets the workspace to the last stable git commit if repair fails, and the daily snapshots feature does an automatic daily git commit of your workspace.

Those two features are the same mechanism seen from two sides, and the daily snapshot is what makes the rollback meaningful. A rollback is only useful if there is a commit worth rolling back to, and the daily commit guarantees that there is one even if the agent has been running for hours without anyone committing anything. Without it, the rollback would land on a commit from whenever the workspace was last set up.

The README's own comparison table makes the point about what the tool adds over a simpler watchdog, listing git rollback, Discord alerts and daily backup as the three capabilities it has where gw-watchdog, the other option it names, has none. The other differences it lists are the check interval, 30 seconds for Guardian against 15 seconds for gw-watchdog, and the action, a fast restart for gw-watchdog against doctor --fix and then rollback for Guardian.

That table is a fair summary of the trade. A faster check with a fast restart is the right choice for a process that merely stopped. A slower check with escalating repair is the right choice for a process that is running but wrong.

The cost of the daily snapshot is that the workspace becomes a git repository with a commit every day, whether or not anything interesting changed, and the rollback discards any uncommitted work as well as anything committed after the last snapshot.

## Five environment variables, and what the defaults actually do

The configuration is a table of five variables, which is small enough to read in full.

| Variable | Default | Description |
|---|---|---|
| `GUARDIAN_WORKSPACE` | `$HOME/.openclaw/workspace` | Workspace git repo path |
| `GUARDIAN_CHECK_INTERVAL` | `30` | Health check interval (seconds) |
| `GUARDIAN_MAX_REPAIR` | `3` | Max repair attempts before rollback |
| `GUARDIAN_COOLDOWN` | `300` | Cooldown after all repairs fail (seconds) |
| `DISCORD_WEBHOOK_URL` | _(unset)_ | Discord webhook for alerts (optional) |

Two of these are the ones you will want to think about before deploying. GUARDIAN_MAX_REPAIR at 3 means three doctor --fix attempts before the workspace is reset, and if your agent is failing in a way that doctor can fix slowly, three attempts might not be enough. GUARDIAN_COOLDOWN at 300 seconds means that after a failed rollback the script sleeps for five minutes before looking again, which is a sensible backoff but also means a broken gateway can sit unnoticed for five minutes at a time.

GUARDIAN_WORKSPACE defaults to the standard OpenClaw workspace path under your home directory, and it is the path the script will run git commands in, so it has to be the same directory you initialised as a repository.

The Discord webhook is optional and unset by default, which is the right default for a tool that might be running on a machine you do not own.

## Installing it: git init, copy the script, run it under nohup

The Quick Start is three steps, and the first one is the one people skip.

```bash
# 1. Initialize git in workspace
cd ~/.openclaw/workspace
git init && git add -A && git commit -m "initial"

# 2. Install
cp scripts/guardian.sh ~/.openclaw/guardian.sh
chmod +x ~/.openclaw/guardian.sh

# 3. Start
nohup ~/.openclaw/guardian.sh >> /tmp/openclaw-guardian.log 2>&1 &
```

The initial commit matters more than it looks. It is the commit the rollback will land on if the first recovery attempt fails, and the git init and git add -A and git commit sequence means whatever is in the workspace at install time becomes that fallback state. If you install into a workspace that already contains a broken configuration, you have made that broken state the recovery point.

The install step copies scripts/guardian.sh from the repository to ~/.openclaw/guardian.sh and makes it executable. The start step runs it with nohup, appending output to a log file under /tmp.

Two things about that start command are worth naming. nohup and the trailing ampersand are how the script survives the terminal closing, which matters because the watchdog is meant to outlive your shell session. And the log goes to /tmp, which is the conventional place for it but also the place a system cleanup will eventually reach, so if you care about the history of failures you should move it somewhere persistent.

There is a second installation route for OpenClaw users, given as a single command.

```bash
clawhub install myclaw-guardian
```

And for OpenClaw users specifically, the README describes a one-line deploy where you tell your AI agent to install openclaw-guardian to harden my gateway, and the agent handles the git init, the script install and the auto-start with no terminal needed. That is an unusual deployment story, and it is a good indication of what this project is for.

## Where the watchdog stops and the monitoring starts

The gap in this project is alerting, and it is worth being blunt about it.

The Discord alerts are described as optional webhook notifications on failures and recovery, which means the script can tell you it lost the gateway. What the flow diagram does not show is an alert before the rollback. The sequence is repair, then rollback, then only afterwards the notification about failure and recovery. By the time a message arrives in your Discord channel, the workspace may already have been reset to the last commit.

For a personal agent whose workspace contains only its own configuration and some generated output, that is fine. For an agent whose workspace is a repository you are working in, an unattended git reset is a serious event, and the tool will perform it without asking.

The second gap is the same one the comparison table exposes. The README is careful to say that gw-watchdog checks every 15 seconds against Guardian's 30, and that its action is a fast restart. So if what you need is a quick restart of a hung process, the other tool is better at it, and Guardian is the one that escalates to a git reset. Those are different failure responses, not different qualities.

There is also the question of what counts as down. The README says Guardian checks Gateway health every 30 seconds, and the configuration exposes the interval, but it does not describe what the health check actually queries or what response counts as a failure. The scripts/ directory is where that lives, and the references/ directory and the SKILL.md file at the repository root are where the rest of the documentation sits.

## Conclusion

Adopt openclaw-guardian if you run an OpenClaw Gateway on a machine where a hung or crashed agent costs you time and you already keep the workspace in git, since the rollback depends on that. Do not adopt it if you need monitored recovery for something other than OpenClaw, or if your workspace is not a git repository, because the rollback path has nothing to roll back to. Before you start it, commit your workspace so the initial commit is clean, and set the repair and cooldown values deliberately rather than leaving the defaults for a production agent.

## FAQ

### What does openclaw-guardian do?

It is a guardian watchdog for the OpenClaw Gateway that checks health every 30 seconds, runs openclaw doctor --fix on failure up to 3 attempts, rolls the workspace back to the last stable git commit if repair fails, makes a daily git commit snapshot, and can send optional Discord webhook notifications on failures and recovery.

### How do I install openclaw-guardian?

The Quick Start is to initialise git in ~/.openclaw/workspace with git init, git add -A and a commit, copy scripts/guardian.sh to ~/.openclaw/guardian.sh, make it executable, and start it with nohup, logging to /tmp/openclaw-guardian.log. OpenClaw users can also run clawhub install myclaw-guardian.

### Which environment variables does openclaw-guardian use?

GUARDIAN_WORKSPACE for the workspace git repo path, GUARDIAN_CHECK_INTERVAL for the health check interval in seconds, GUARDIAN_MAX_REPAIR for the number of repair attempts before rollback, GUARDIAN_COOLDOWN for the cooldown after all repairs fail, and the optional DISCORD_WEBHOOK_URL.

### How does openclaw-guardian differ from gw-watchdog?

The README's comparison table lists the differences: gw-watchdog checks every 15 seconds against Guardian's 30, and its action is a fast restart against Guardian's doctor --fix then rollback. Guardian adds git rollback, Discord alerts and a daily backup, which gw-watchdog does not have.

## Sources

- [Issues](https://github.com/LeoYeAI/openclaw-guardian/issues)
- [LeoYeAI/openclaw-guardian on GitHub](https://github.com/LeoYeAI/openclaw-guardian)
- [License: MIT](https://github.com/LeoYeAI/openclaw-guardian/blob/main/LICENSE)
- [Project website](https://myclaw.ai)
- [README](https://github.com/LeoYeAI/openclaw-guardian/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leoyeai-openclaw-guardian