Adapted community discussion: Paraphrased and condensed from an anonymized public OpenClaw Discord support conversation from July 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.
After an update, my Linux Gateway service is enabled but exits with code 1. The local probe gets connection refused, and restarting does not bring it back.
Connection refused is the consequence of the process exiting. Capture the startup failure and check whether the service and shell use the same installation:
openclaw --version
which -a openclaw
openclaw gateway status --deep
openclaw config validate
openclaw plugins doctor
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
Do not kill processes or reinstall state until the first fatal line is identified.
Configuration validation reports that a web-search plugin is still configured, but its installed package contains only a TypeScript entry and no compiled JavaScript runtime file.
That malformed plugin package can block startup. If the plugin is optional, isolate it reversibly:
openclaw plugins disable <plugin-id>
openclaw config validate
openclaw gateway restart
openclaw gateway status --deep
If its stale config remains after disabling, inspect the exact entry and remove only that plugin entry with openclaw config unset. Keep the rest of the configuration intact. Reinstall the plugin only after a compatible built package is available.
I rolled the OpenClaw package back, but the Gateway still will not restart.
A code rollback does not remove the configured plugin entry. Later diagnostics also showed a split installation, with the service invoking an older OpenClaw than the interactive shell. Resolve both conditions: use the intended current CLI, disable the broken plugin, then regenerate the managed service with openclaw gateway install --force. Verify the effective command with openclaw gateway status --deep before removing any older installation.