OpenClaw Profiles and the Rescue Bot: What a Second Gateway on the Same Machine Can and Can't Save

openclaw --profile rescue gives you a second Gateway with its own config, state, workspace, service name, and port, all on the machine you already have. It is the cheapest insurance OpenClaw offers. It also covers less than people assume.

The results that rank for this are the official multiple-gateways page and a handful of mirrors of it (mostly jsDelivr copies of old npm tarballs, plus the docs.claw.so fork). They agree on the isolation checklist and the quickstart. None of them says which failures a rescue bot on the same host will sit through just as dead as your main one, and that is the decision that matters before you spend an evening onboarding a second Telegram bot. Some of the mirrors are also stale in a way that bites, which gets its own section.

What a profile actually isolates

openclaw --profile rescue onboard
openclaw --profile rescue gateway install --port 19789

A named profile moves state to ~/.openclaw-rescue and points OPENCLAW_STATE_DIR and OPENCLAW_CONFIG_PATH there. The state directory is where sessions and credentials live (caches too), so the rescue Gateway logs in to its model provider separately and keeps its own channel tokens. It also gets its own service: on macOS the LaunchAgent label is ai.openclaw.rescue instead of ai.openclaw.gateway, on Linux it is openclaw-gateway-rescue.service, and on Windows the task is OpenClaw Gateway (rescue).

That last part is why you should use --profile instead of only changing OPENCLAW_STATE_DIR. The docs carry a warning that the state directory alone does not isolate a managed service, because service names follow the profile. Install a service with only a temp state dir set and you are reinstalling the default one.

One inconsistency to check yourself. The multiple-gateways page says the rescue workspace defaults to ~/.openclaw/workspace-rescue, while the workspace concept page says a named profile defaults to ~/.openclaw-rescue/workspace. In my copy of the CLI (2026.10.5) both pages ship side by side. Ask the tool instead of either page:

openclaw --profile rescue config get agents.defaults.workspace

The 20-port advice is out of date

Older copies of the docs, still served from jsDelivr and still ranking, say to leave at least 20 ports between base ports and use 19001 for the rescue bot. The current page says 120, and the arithmetic explains why: the browser control service sits at base + 2, and browser profiles take CDP ports from control + 9 through control + 108, so each instance reaches base + 110.

The old example port has a second problem. 19001 is exactly where openclaw --dev puts its Gateway by default. Follow the stale mirror, then try the dev profile a month later, and the dev Gateway fails to bind because your rescue bot already holds the port. Put the rescue bot at 19789 like the current quickstart does and both fit, with the default Gateway at 18789 and dev at 19001 sitting more than 120 ports from each.

Two flags called --dev

openclaw --dev gateway and openclaw gateway --dev do different things. The first is a global profile: state in ~/.openclaw-dev, port 19001, derived ports shifted to match. The second tells the Gateway to create a minimal config and workspace if they are missing and skip BOOTSTRAP.md, which is why a fresh dev agent introduces itself as C3-PO. You usually want both. Some runners swallow the global flag, so the docs suggest the env form:

OPENCLAW_PROFILE=dev openclaw gateway --dev --reset

--reset only works with gateway --dev. It moves the dev config, credentials, sessions, and workspace to the trash and seeds them again. Nothing in your main profile is touched, which makes the dev profile the right place to try a config change you aren't sure about.

What a rescue bot on the same machine can't save you from

Start with what it does cover, because that list is real. If you break openclaw.json and the main Gateway won't start, the rescue Gateway reads a different file. A revoked main Telegram token doesn't matter either, since the rescue bot has its own. And when the main Gateway wedges while holding its state lock, the rescue Gateway owns a different state directory and never waits on it. That is the scenario the docs built this for: a DM lane that still answers while you run openclaw doctor against the broken profile.

Now the gaps. A profile isolates state and config. It does not isolate code. Both Gateways run the one OpenClaw package installed on the machine (on mine, a single dist/entry.js under Homebrew's global node_modules), so a release with a bug that kills your main Gateway kills the rescue Gateway too, on the same restart. The rescue profile is no substitute for a rollback plan, and the upgrade guide has the one I trust. After any update, the docs say to refresh each service definition with openclaw gateway install --force using the same --profile or --dev option, which means one run per profile.

The machine is shared too. A Mac mini that loses power, or one where memory pressure starts handing out SIGTERMs, takes both Gateways down together. A model provider outage does the same if both profiles use the same provider, and since each profile logs in separately there is no reason they have to. I would put the rescue bot on a different provider from the main agent, even a weaker and cheaper one. A rescue bot only needs to read a log and run a command.

That command is the part to plan. A rescue agent that can fix your main config needs exec access on the host, plus a channel token. That is a powerful lane with a phone number attached. Gate it with exec approvals and an operator-only DM policy before you trust it at 2 a.m. If you want that lockdown done as a checklist instead of by trial, the Security Hardening Kit on the OpenClaw products page covers tool permission boundaries for a 24/7 agent, which is what a rescue bot is.

Host down means a second host, full stop.

If you need that, the cleaner shape is a Gateway on another machine reached over Tailscale, and the backup and migration guide shows how to get state onto it.

Checking that both are alive

openclaw gateway status --deep
openclaw --profile rescue gateway status --deep
openclaw --profile rescue gateway probe
openclaw --profile rescue browser status

gateway probe will warn about multiple reachable gateway identities. With a rescue bot running that warning is expected and means the setup is doing its job. status --deep is the more useful one: it finds stale launchd or systemd entries from older installs, and a leftover service is how people end up with a third Gateway nobody remembers starting. Put the profile flag on every command, in scripts and in your own shell history. Global options go before the command word, so it is openclaw --profile rescue logs --follow, and the logging guide covers where each profile writes. When you retire a profile, the uninstall guide has the per-profile commands.

Final verdict

Set up the rescue profile. It costs one extra Telegram bot and one more onboarding run, and it turns "I broke my config from my phone" into a recoverable afternoon. Give it port 19789, a different model provider, and gated exec. Then stop thinking of it as redundancy, because it shares the installed package and the power cord with the bot it is supposed to rescue. For a bad release, your rollback script is the safety net. For a dead machine, nothing on that machine will help.