solution gateway high macos

macOS: gateway stays down after VPN reconnect

Fix macOS cases where the OpenClaw gateway does not recover after a VPN/network drop by clearing cold-start config blockers and refreshing the launchd service install.

By CoClaw Team • March 7, 2026

Symptoms

A VPN drop or network interruption causes the gateway to stop.
After connectivity comes back, the gateway does not recover by itself.
openclaw gateway restart may help once, but the problem returns after the next drop.
On macOS, this often shows up as a launchd-supervised gateway that looks installed but does not reliably come back to a healthy running state.
In some setups, a config problem only becomes visible on cold start, so the gateway cannot self-heal after the VPN outage.

Cause

This is usually two problems stacked together:

The VPN/network outage is the first trigger that stops or destabilizes the gateway.
When the gateway tries to come back, one of these recovery blockers prevents self-healing:
- cold-start config validation fails, or
- the macOS launchd service install/runtime is stale after updates or path changes.

One common cold-start blocker is Telegram DM config:

if channels.telegram.dmPolicy is "open", then channels.telegram.allowFrom must include "*".

If that invariant is broken, the gateway may seem fine while already running, but fail when it needs a clean restart after the VPN event.

Fix

1) Make sure the gateway can cold-start cleanly

Run doctor first:

openclaw doctor

If it reports repairable config issues, apply them:

openclaw doctor --fix

If you intentionally use Telegram DMs with dmPolicy: "open", verify the allowlist is compatible:

openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom

If dmPolicy is "open", ensure the running config includes "*" in channels.telegram.allowFrom.

Why this helps: after a VPN drop, the gateway can only self-heal if a clean restart path is valid.

2) Refresh the macOS supervised service install

Rewrite the gateway service to current defaults, then restart it:

openclaw gateway install --force
openclaw gateway restart

If you originally installed the daemon via onboarding, rerunning this is also fine:

openclaw onboard --install-daemon

Why this helps: if launchd is supervising an old runtime path, old package root, or stale service definition, a plain restart may not be enough.

3) Re-test one network-loss cycle after both fixes

Once config validity and service installation are both clean, reproduce one VPN disconnect/reconnect cycle and watch the gateway state:

openclaw gateway status
openclaw status --deep

Verify

openclaw doctor no longer reports blocking config errors.
openclaw gateway status shows the service as running after a restart.
After one VPN reconnect test, the gateway comes back without needing manual intervention.
Telegram/WhatsApp/other channels recover once the network path is back.

If the gateway still stays down, collect:

openclaw doctor output,
openclaw gateway status,
openclaw status --deep,
and the first gateway logs after the VPN reconnect.