gateway issues | Friends of the Crustacean 🦞🤝 | Page 1

visual orbitBOT Apr 7, 2026, 11:39 AM

#

Yep — that error is usually just stale remote creds.

Set the client token to exactly match the gateway’s auth token:

# run on the gateway host
openclaw config get gateway.auth.token

# run on the client machine that connects remotely
openclaw config set gateway.remote.token "<paste-the-token>"

Then retry:

openclaw status

#

If it still fails, paste these outputs (first line especially matters):

openclaw --version
openclaw config get gateway.mode
openclaw gateway status

Docs: https://docs.openclaw.ai/gateway/remote and https://docs.openclaw.ai/gateway/troubleshooting#dashboard-control-ui-connectivity

plain raft Apr 7, 2026, 11:40 AM

#

Bug Report — Recurring crash: "Agent listener invoked outside active run"

Version: OpenClaw 2026.4.5 (3e72c03)
OS: Debian 6.12.74 (Docker container)
Node: v22.22.2

Description:
OpenClaw crashes repeatedly with Unhandled promise rejection: Error: Agent listener invoked outside active run. The crash happens when a cron job (claude-haiku-4-5) runs an exec tool, and the spawned process emits on stderr after the agent run has already completed.

Frequency: 3-4 times per day, causing complete gateway shutdown each time.

Stack trace:
Agent.processEvents (agent.ts:533)
→ agent.ts:380
→ Object.onUpdate (agent-loop.ts:539)
→ emitUpdate (exec-defaults-uj0McX2k.js:1524)
→ Object.handleStderr (exec-defaults-uj0McX2k.js:1553)
→ Socket.emit (node:events:519)
Reproduction: Happens when cron jobs use exec tool. The stderr listener fires after the run is complete, causing the unhandled rejection.

Workaround: docker update --restart=unless-stopped to auto-restart the container.

visual orbitBOT Apr 7, 2026, 11:41 AM

#

This looks like a real 2026.4.5 crash, not config error.
Your stack (Agent.processEvents + exec-defaults...handleStderr) matches this open bug: https://github.com/openclaw/openclaw/issues/61733

If you can, please add your report there (Docker + cron/exec details are super useful).
Include:

exact cron job payload (openclaw cron get <jobId> --json)
30–60s of logs before crash (openclaw logs --follow)
whether the command spawns child/background processes that keep writing to stderr

Temporary mitigation (until a patch release lands): keep container restart policy enabled (unless-stopped), and avoid cron exec commands that leave child stderr streams alive after the parent exits.

lime sonnet Apr 7, 2026, 11:42 AM

#

openclaw config get gateway.auth.token returns OPENCLAW_REDACTED in cli no actual token

visual orbitBOT Apr 7, 2026, 11:43 AM

#

Yep — that’s expected. gateway.auth.token is treated as sensitive, so config get can show __OPENCLAW_REDACTED__ instead of the raw value.

Fastest path: set a new token you know and use it on both sides.

# on the gateway host
TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway restart

# on the remote client
openclaw config set gateway.remote.token "<same TOKEN>"

#

Then retry openclaw status.

Also: openclaw doctor --generate-gateway-token only fills a missing token; it won’t rotate an existing one.

Docs: https://docs.openclaw.ai/gateway/remote and https://docs.openclaw.ai/web/dashboard#if-you-see-unauthorized-1008

lime sonnet Apr 7, 2026, 2:17 PM

#

⚠️ Config token differs from service token. The daemon will use the old token after restart.
Run openclaw gateway install --force to sync the token.

Restarted systemd service: openclaw-gateway.service

visual orbitBOT Apr 7, 2026, 2:18 PM

#

Nice catch — that warning is the root cause.
Your service is still pinned to the old token.

Run this on the gateway host:

openclaw gateway install --force
openclaw gateway restart

Then verify:

openclaw gateway status
openclaw status

#

And make sure the client still has the same token in gateway.remote.token.

If it still mismatches after install --force, check for a leftover service env override (OPENCLAW_GATEWAY_TOKEN) in systemd user env.

lime sonnet Apr 7, 2026, 2:20 PM

#

config token still differs

visual orbitBOT Apr 7, 2026, 2:20 PM

#

Got it — if it still differs after install --force, it’s usually one of these:

Service is using a different profile/state dir

openclaw gateway status

Check Config (cli) vs Config (service) paths.

systemd user env is overriding token (OPENCLAW_GATEWAY_TOKEN wins over config):

systemctl --user show-environment | grep OPENCLAW_GATEWAY
systemctl --user unset-environment OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD

Reinstall + restart from the same profile you actually run:

#

openclaw gateway install --force
openclaw gateway restart

(If you use a profile: openclaw --profile <name> gateway install --force)

Then re-check:

openclaw gateway status
openclaw status

If you paste openclaw gateway status output, I can pinpoint which of the three it is.

lime sonnet Apr 7, 2026, 2:29 PM

#

Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled. (Run │
│ openclaw gateway install --force to remove embedded service token.) │
│ - Gateway service OPENCLAW_GATEWAY_TOKEN does not match gateway.auth.token in │
│ openclaw.json (service token is stale) , ◇ Gateway ──────────────╮
│ │
│ Gateway not running. .. already ran the openclaw gateway install --force` and openclaw doctor --repair

visual orbitBOT Apr 7, 2026, 2:30 PM

#

Yeah, this is a service metadata drift loop.

If install --force didn’t clear it, do a full service reset + env cleanup:

openclaw gateway stop
systemctl --user unset-environment OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start

Then check:

#

openclaw gateway status
openclaw status

If it still says stale token, paste these 3 outputs and I’ll pinpoint exactly where it’s coming from:

openclaw config file
openclaw gateway status --json
systemctl --user cat openclaw-gateway.service

(Usually it’s either a leftover systemd env override or a different profile/state path than expected.)

lime sonnet Apr 7, 2026, 2:40 PM

#

"configAudit": {
"ok": false,
"issues": [
{
"code": "gateway-token-embedded",
"message": "Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled.",
"detail": "Run openclaw gateway install --force to remove embedded service token.",
"level": "recommended"
}

visual orbitBOT Apr 7, 2026, 2:40 PM

#

Nice — this confirms the specific audit flag.

gateway-token-embedded is a legacy service-unit issue (token hardcoded in systemd unit env).
If install --force didn’t clear it, there’s usually a lingering systemd override/drop-in.

Try this exact cleanup on the gateway host:

systemctl --user cat openclaw-gateway.service | grep OPENCLAW_GATEWAY_TOKEN -n || true
systemctl --user revert openclaw-gateway.service || true
mv ~/.config/systemd/user/openclaw-gateway.service.d ~/.config/systemd/user/openclaw-gateway.service.d.bak 2>/dev/null || true
systemctl --user daemon-reload

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

#

If you use a profile, do the same for openclaw-gateway-<profile>.service (that’s a common gotcha).
Docs: https://docs.openclaw.ai/gateway/troubleshooting

lime sonnet Apr 7, 2026, 2:43 PM

#

and still ⚠️ Config token differs from service token. The daemon will use the old token after restart.
Run openclaw gateway install --force to sync the token.

visual orbitBOT Apr 7, 2026, 2:44 PM

#

You’re in a sticky drift state.
Let’s force everything to one known token in one pass.

# 1) pick a fresh token
TOKEN="$(openssl rand -hex 32)"

# 2) write it to config
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"

# 3) fully recreate user systemd unit
openclaw gateway stop || true
openclaw gateway uninstall || true
mv ~/.config/systemd/user/openclaw-gateway.service ~/.config/systemd/user/openclaw-gateway.service.bak 2>/dev/null || true
mv ~/.config/systemd/user/openclaw-gateway.service.d ~/.config/systemd/user/openclaw-gateway.service.d.bak 2>/dev/null || true

#

systemctl --user daemon-reload

# 4) reinstall + start fresh
openclaw gateway install --force
openclaw gateway start

Then on the client side set the same token:

openclaw config set gateway.remote.token "$TOKEN"

This bypasses whatever stale embedded token keeps surviving.
If this still reports drift, paste systemctl --user cat openclaw-gateway.service and openclaw gateway status --json (redact secrets).

visual orbitBOT Apr 7, 2026, 3:32 PM

#

Perfect — this output is different now.

You’re no longer showing the token mismatch/drift error, only:

gateway-token-embedded (recommended warning)

That one is annoying, but it’s not a hard failure by itself.
If your connect/auth works now, you can proceed.

If you want to remove the warning cleanly, switch to env-file token source:

TOKEN="$(openssl rand -hex 32)"
echo "OPENCLAW_GATEWAY_TOKEN=$TOKEN" > ~/.openclaw/.env

openclaw config set gateway.auth.mode token

#

openclaw config set gateway.auth.token --ref-provider default --ref-source env --ref-id OPENCLAW_GATEWAY_TOKEN
openclaw gateway install --force
openclaw gateway restart

# remote client
openclaw config set gateway.remote.token "$TOKEN"

If you’re still getting unauthorized after this, paste just:

openclaw gateway status
openclaw config get gateway.mode
openclaw config get gateway.remote.url

lime sonnet Apr 7, 2026, 3:46 PM

#

nothing seems to fix it whats a more serious reset on that part

visual orbitBOT Apr 7, 2026, 3:47 PM

#

Yep — let’s do a hard reset of gateway auth + daemon only (not full OpenClaw wipe).

1) Hard reset (service + token path)

# stop/remove current daemon
openclaw gateway stop || true
openclaw gateway uninstall || true
systemctl --user unset-environment OPENCLAW_GATEWAY_TOKEN OPENCLAW_GATEWAY_PASSWORD || true
mv ~/.config/systemd/user/openclaw-gateway.service ~/.config/systemd/user/openclaw-gateway.service.bak.$(date +%s) 2>/dev/null || true
mv ~/.config/systemd/user/openclaw-gateway.service.d ~/.config/systemd/user/openclaw-gateway.service.d.bak.$(date +%s) 2>/dev/null || true
systemctl --user daemon-reload

# force one known token everywhere
TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.mode local

#

openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw config set gateway.remote.token "$TOKEN"

# reinstall/start clean service
openclaw gateway install --force
openclaw gateway start
openclaw status

2) If that still fails (nuclear option)

openclaw reset --scope full --yes --non-interactive
openclaw onboard --install-daemon

#

(That second one is full wipe/re-onboard.)

If you run step 1 and paste openclaw gateway status after, I can sanity-check immediately.

lime sonnet Apr 7, 2026, 3:48 PM

#

which files to backup before a reset and is option 1 gonna delete env etc too?

visual orbitBOT Apr 7, 2026, 3:48 PM

#

Great question.

Option 1 does not delete your whole env/state.
It only:

unsets systemd manager env overrides (OPENCLAW_GATEWAY_TOKEN/PASSWORD)
renames service unit files to .bak...
rewrites gateway.auth.token + gateway.remote.token in openclaw.json

It does not delete ~/.openclaw/.env, sessions, memory, or workspace.

Backup before any reset (recommended)

Back up these:

State dir (usually ~/.openclaw)

includes config, sessions, creds, auth profiles, logs

#

Workspace dir (usually ~/.openclaw/workspace or your custom path)
Optional extra safety: service unit files in ~/.config/systemd/user/

Quick backup:

STATE="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
WS="$HOME/.openclaw/workspace" # change if custom
STAMP="$(date +%F_%H%M%S)"

mkdir -p "$HOME/openclaw-backups"
cp -a "$STATE" "$HOME/openclaw-backups/state-$STAMP"
cp -a "$WS" "$HOME/openclaw-backups/workspace-$STAMP" 2>/dev/null || true

If you do full reset (openclaw reset --scope full), that’s when these backups really matter.

lime sonnet Apr 7, 2026, 3:49 PM

#

15:49:08+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram command sync failed: HttpError: Network request for 'setMyCommands' failed!

visual orbitBOT Apr 7, 2026, 3:49 PM

#

That one is a separate issue from token drift — it’s Telegram API reachability.

setMyCommands failed: Network request ... failed usually means the gateway host can’t reliably reach api.telegram.org (DNS/egress/proxy/firewall hiccup).

Quick checks:

openclaw channels status
openclaw channels logs --channel telegram

If this keeps repeating, test network from the same host/container to api.telegram.org (DNS + outbound HTTPS).
Also verify you’re not behind a proxy/VPN that intermittently blocks Telegram.

Docs refs:

#

Yep — confirmed: this is DNS, not Telegram auth.

curl: (6) Could not resolve host: api.telegram.org means your gateway host/container can’t resolve DNS.

Fast fixes:

Test DNS directly:

getent hosts api.telegram.org
nslookup api.telegram.org

If running in Docker/Compose, set explicit resolvers for the container (common fix), e.g.:

dns:
- 1.1.1.1

#

- 8.8.8.8

If running on host systemd/Linux, fix resolver (/etc/resolv.conf / systemd-resolved) and ensure outbound UDP/TCP 53 is allowed.

Once DNS works, setMyCommands errors should disappear automatically.
(Separate from the gateway token mismatch thread.)

lime sonnet Apr 7, 2026, 4:59 PM

#

openclaw update seems to have fixed it even tho its very not stable and sometimes it stops responding and needs restart

visual orbitBOT Apr 7, 2026, 5:00 PM

#

Nice, glad update unblocked the token mess 🙌

For the “stops responding until restart” part, let’s capture a clean repro so it can be fixed properly:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw logs --follow

When it hangs, grab those outputs and file it here:
https://github.com/openclaw/openclaw/issues

If you want, I can help you format a solid bug report from the logs so maintainers can reproduce it faster.

lime sonnet Apr 7, 2026, 5:02 PM

#

randomly get Gateway not reachable. Is it running and accessible?

visual orbitBOT Apr 7, 2026, 5:03 PM

#

Yep, that message means the CLI couldn’t reach the gateway WS endpoint at that moment.

Quick triage (in order):

openclaw gateway status
openclaw status
openclaw config get gateway.mode
openclaw config get gateway.remote.url
openclaw logs --follow

What it usually is:

service crashed/restarting
wrong URL target (gateway.mode=remote pointing to unreachable host)
auth mismatch after restart

#gateway issues

1) Hard reset (service + token path)

2) If that still fails (nuclear option)

Backup before any reset (recommended)