gateway is dead since migrating secrets

[hollow spade]

I just had my agent migrate the secret part of the new update. But now my gateway won't start :
Runtime: stopped (state activating, sub auto-restart, last exit 1, reason 1)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/deck/.openclaw/openclaw.json

Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-02-27.log
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

[dusky tulip]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[alpine fossil]

A WS 1006 here just means “the gateway process died / closed without a clean shutdown” — the real reason will be a fatal error in the logs right before it exits.

Can you paste these (they’re the fastest way to pinpoint it), and also tell us what exact command you used to “migrate secrets” + your openclaw --version?

1. Versions

openclaw --version
node --version

2. Redacted, paste-safe report (preferred)

openclaw status --all

3. The crash details

tail -n 200 /tmp/openclaw/openclaw-2026-02-27.log
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Common “right after an update/migration” causes (we’ll confirm via the log):

• Config syntax break in ~/.openclaw/openclaw.json (it’s JSON5, not YAML)
• Node too old (OpenClaw needs Node >= 22)
• Service/config mismatch (service running with a different profile/state dir than the CLI)

Docs reference for the above ladder: https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken and https://docs.openclaw.ai/gateway/troubleshooting#gateway-service-not-running

[hollow spade]

version: 2026.2.26
node : 22.22
Overview
│ Item │ Value
│ Version │ 2026.2.26
│ OS │ linux 6.11.11-valve26-1-neptune-611-gb3afa9aa9ae7 (x64)
│ Node │ 22.22.0
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ off · Running · steam#redacted#
│ Channel │ stable (default)
│ Update │ pnpm · npm latest 2026.2.26
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable (connect failed: connect ECONNREFUSED 127.0.0.1:18789)
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ systemd installed · enabled · running (pid 204505)
│ Node service │ systemd not installed
│ Agents │ 7 total · 0 bootstrapping · 0 active · 76 sessions
Channels
│ Channel │ Enabled │ State │ Detail
│ Telegram │ ON │ SETUP │ no token
│ WhatsApp │ ON │ OK │ linked · +#redacted#· auth 30m ago · accounts 1
│ Discord │ ON │ OK │ token config×7 (sha256:aa61557a · len 72) · accounts 7/7
WhatsApp accounts
│ Account │ Status │ Notes
│ default │ OK │ dm:allowlist · allow:+33#redacted#
Discord accounts
│ Account │ Status │ Notes
│ atlas (Atlas) │ OK │ token:config
│ bastion (Bastion) │ OK │ token:config
│ forge (Forge) │ OK │ token:config
│ nox (Nox) │ OK │ token:config
│ plume (Plume) │ OK │ token:config
│ sentinel (Sentinel) │ OK │ token:config
│ siren (Siren) │ OK │ token:config
Agents

│ Agent │ Bootstrap file │ Sessions │ Active │ Store
│ nox (Nox) │ ABSENT │ 55 │ 33m ago │ ~/.openclaw/agents/nox/sessions/sessions.json
│ atlas (Atlas) │ ABSENT │ 13 │ 1h ago │ ~/.openclaw/agents/atlas/sessions/sessions.json
│ bastion (Bastion) │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/bastion/sessions/sessions.json
│ forge (Forge) │ ABSENT │ 2 │ 25h ago │ ~/.openclaw/agents/forge/sessions/sessions.json
│ plume (Plume) │ ABSENT │ 1 │ 16h ago │ ~/.openclaw/agents/plume/sessions/sessions.json
│ sentinel (Sentinel) │ ABSENT │ 4 │ 18h ago │ ~/.openclaw/agents/sentinel/sessions/sessions.json
│ siren (Siren) │ ABSENT │ 1 │ 12h ago │ ~/.openclaw/agents/siren/sessions/sessions.json

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/deck/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/deck/.openclaw/openclaw.json
✓ Restart sentinel: none
✓ Port 18789
✓ Tailscale: off · Running · s#redacted#
ips: #redacted#, #redacted#
✓ Skills: 8 eligible · 0 missing · /home/deck/.openclaw/workspace
! Channel issues skipped (gateway unreachable)
Gateway health:
connect failed: connect ECONNREFUSED 127.0.0.1:18789

[alpine fossil]

Nice, thanks — versions look fine (2026.2.26 + Node 22.22). Given:

• systemd … auto-restart … last exit 1
• ECONNREFUSED 127.0.0.1:18789

…the gateway is crashing before it ever starts listening. The next step is: get the actual fatal error from the log right before exit.

Can you paste just the last crash block from one of these (whichever has the stacktrace)?

Option A (usually best)

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Option B (file log)

tail -n 200 /tmp/openclaw/openclaw-2026-02-27.log

If you want to pre-filter to avoid noise:

rg -n "FATAL|Unhandled|Exception|SyntaxError|EADDRINUSE|refusing to bind|missing|env" \
/tmp/openclaw/openclaw-2026-02-27.log | tail -n 80

Also quick sanity check (in case it bound to IPv6-only or a different port):

ss -ltnp | rg ":18789"

Once we see the exact error line, it’s usually a 1-liner fix (common after “secret migration”: missing env var / missing tokenFile / auth mode wants a token but it got blanked).

[hollow spade]

Feb 27 11:21:17 steamdeck systemd[1541]: openclaw-gateway.service: Scheduled restart job, restart counter is at 274.
Feb 27 11:21:17 steamdeck systemd[1541]: Started OpenClaw Gateway (v2026.2.25).
Feb 27 11:21:19 steamdeck node[206410]: │
Feb 27 11:21:19 steamdeck node[206410]: ◇ Doctor changes ──────────────────────────────────────────────╮
Feb 27 11:21:19 steamdeck node[206410]: │ │
Feb 27 11:21:19 steamdeck node[206410]: │ Moved channels.discord single-account top-level values into │
Feb 27 11:21:19 steamdeck node[206410]: │ channels.discord.accounts.default. │
Feb 27 11:21:19 steamdeck node[206410]: │ │
Feb 27 11:21:19 steamdeck node[206410]: ├───────────────────────────────────────────────────────────────╯
Feb 27 11:21:19 steamdeck node[206410]: │
Feb 27 11:21:19 steamdeck node[206410]: ◇ Doctor ──────────────────────────────────────────────╮
Feb 27 11:21:19 steamdeck node[206410]: │ │
Feb 27 11:21:19 steamdeck node[206410]: │ Run "openclaw doctor --fix" to apply these changes. │
Feb 27 11:21:19 steamdeck node[206410]: │ │
Feb 27 11:21:19 steamdeck node[206410]: ├───────────────────────────────────────────────────────╯
Feb 27 11:21:19 steamdeck node[206410]: 2026-02-27T10:21:19.958Z [secrets] [SECRETS_RELOADER_DEGRADED] Error: Environment variable "MOONSHOT_API_KEY" is missing or empty.
Feb 27 11:21:19 steamdeck node[206410]: 2026-02-27T11:21:19.996+01:00 Gateway failed to start: Error: Startup failed: required secrets are unavailable. Error: Environment variable "MOONSHOT_API_KEY" is missing or empty.
Feb 27 11:21:20 steamdeck systemd[1541]: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE
Feb 27 11:21:20 steamdeck systemd[1541]: openclaw-gateway.service: Failed with result 'exit-code'.
Feb 27 11:21:20 steamdeck systemd[1541]: openclaw-gateway.service: Consumed 3.775s CPU time, 245.6M memory peak.

[alpine fossil]

Logs already tell us the exact blocker:

Startup failed: required secrets are unavailable. Environment variable "MOONSHOT_API_KEY" is missing or empty.

So the “secrets migration” made MOONSHOT_API_KEY a required secret for your current config, and systemd is restarting the gateway in a crash loop.

Fix (pick one)

A) You actually use Moonshot/Kimi models → set the env var on the gateway host

1. Stop the restart spam while you edit:

systemctl --user stop openclaw-gateway.service

2. Add the key to the gateway service env (recommended place on Linux/systemd is ~/.openclaw/.env):

nano ~/.openclaw/.env
# add:
# MOONSHOT_API_KEY=sk-...

(Do not paste the key into Discord.)

3. Restart + verify:

openclaw gateway restart
openclaw gateway status

B) You don’t use Moonshot → remove it from config
Search where it’s referenced and delete/disable that provider/model:

rg -n "MOONSHOT|moonshot" ~/.openclaw/openclaw.json

Then restart:

openclaw gateway restart

One extra thing I notice

Your journal says: Started OpenClaw Gateway (v2026.2.25) but you’re on 2026.2.26. After it boots, run:

openclaw doctor --fix

(and if it still reports CLI/service mismatch, openclaw gateway install --force is usually the cleanup step).

If you paste the rg ... openclaw.json match lines (with secrets redacted), I can tell you exactly what to remove/keep.

[hollow spade]

I moved the key away from the .env using the latest secret to file migration tool in the last openclaw update. Should I return to a .env ?

[alpine fossil]

You don’t have to use ~/.openclaw/.env specifically — but you do need MOONSHOT_API_KEY to be available to the Gateway process as an environment variable (or hardcoded in openclaw.json), because your config is doing ${MOONSHOT_API_KEY} substitution and missing/empty vars hard-fail gateway startup.

So if your “secret→file migration” moved the value into some other file, OpenClaw won’t magically discover it unless that file is loaded into the process env.

Easiest fix (recommended)

Put it back in ~/.openclaw/.env (this is the supported way for services):

systemctl --user stop openclaw-gateway.service

nano ~/.openclaw/.env
# MOONSHOT_API_KEY=sk-...

chmod 600 ~/.openclaw/.env
openclaw gateway restart
openclaw gateway status

If you really want a separate secrets file (not .env)

Create something like ~/.openclaw/secrets.env and tell systemd to load it:

1. Create the file:

nano ~/.openclaw/secrets.env
# MOONSHOT_API_KEY=sk-...

chmod 600 ~/.openclaw/secrets.env

2. Add a systemd drop-in:

systemctl --user edit openclaw-gateway.service

Paste:

[Service]
EnvironmentFile=%h/.openclaw/secrets.env

Then:

systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.service
openclaw gateway status

If you don’t use Moonshot at all

Remove/disable the Moonshot provider bits so ${MOONSHOT_API_KEY} isn’t referenced:

rg -n "moonshot|MOONSHOT" ~/.openclaw/openclaw.json

Docs that match what you’re seeing: https://docs.openclaw.ai/help/environment and https://docs.openclaw.ai/gateway/configuration#env-var-substitution-in-config-values

[hollow spade]

yeah so how can I find the API key ? since my agent moved it I don't know how to access it back

[alpine fossil]

If the key is gone from the Gateway’s environment, OpenClaw can’t “recover” it from Moonshot — it has to be somewhere on your disk (where your agent moved it), or you need to mint a new one in your Moonshot account.

Here’s how to find where it got moved without spraying secrets into Discord:

1) Check what the systemd service is loading (best signal)

This tells you if the migration created an EnvironmentFile=... somewhere:

systemctl --user cat openclaw-gateway.service
systemctl --user show openclaw-gateway.service -p EnvironmentFiles -p Environment

If you see an EnvironmentFile=..., open that file locally and you should find MOONSHOT_API_KEY=....

2) Search the usual places for where it was written

This will likely print the line that contains the key — do not paste the raw output. Use the redacting version:

rg -n --hidden "MOONSHOT_API_KEY" ~/.openclaw ~/.config/systemd/user 2>/dev/null \
| sed -E 's/(MOONSHOT_API_KEY=).*/\\1<redacted>/'

Also check if you have old env backups:

ls -la ~/.openclaw/.env*

3) (Last resort) Shell history

Sometimes an agent wrote it via a command:

rg -n "MOONSHOT_API_KEY" ~/.bash_history ~/.zsh_history 2>/dev/null \

| sed -E 's/(MOONSHOT_API_KEY=).*/\\1<redacted>/'

4) If you truly can’t find it

Assume it’s lost and generate a new Moonshot API key in your Moonshot/Kimi account, then put it back into a place the service actually loads (simplest: ~/.openclaw/.env) and restart.

If you paste the output of (1) (it won’t include the key) and the redacted output of (2), I can tell you exactly where the service expects to load it from.