#How to restore previous version
1 messages · Page 1 of 1 (latest)
terminal gateway status shows: Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /usr/bin/node /home/michael/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
Runtime: running (pid 1704, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
First thing: can you paste:
openclaw --version
openclaw gateway status
openclaw status --all
If only the current session is wedged, try the least invasive fix first: send /new or /reset as a standalone message in that same chat/dashboard session.
If the gateway itself is unhealthy after the update:
openclaw doctor
openclaw gateway restart
Also check logs for this exact kind of error:
devices/pending.json ... Unexpected end of JSON input
If you see that, move the corrupted pending-device file aside and restart:
mv ~/.openclaw/devices/pending.json ~/.openclaw/devices/pending.json.bak
openclaw gateway restart
For rollback, safest package-flow option is usually pinning the previous version:
openclaw update --tag <previous-version> --yes
openclaw doctor
openclaw gateway restart
If the updater itself is too wedged, use pnpm directly:
pnpm add -g openclaw@<previous-version>
openclaw doctor
openclaw gateway restart
Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/gateway/troubleshooting 🦐
That status actually looks healthy: service is running, probe is OK, and it’s admin-capable. So I’d not revert yet — this sounds more like a wedged session/UI state than a broken gateway.
Try this first:
openclaw --version
openclaw status --all
Then in the wedged Dashboard/chat session, send this as a standalone message:
/new
or:
/reset
If the UI itself is stuck, hard-refresh the dashboard after that.
If it’s still wedged, grab the relevant log tail:
openclaw logs --follow
Rollback is still possible, but I’d only do it after we see openclaw --version and the status/log output. If you do need to pin back:
pnpm add -g openclaw@<previous-version>
openclaw doctor
openclaw gateway restart
Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/gateway/troubleshooting
OpenClaw 2026.4.26 (be8c246)
OpenClaw status --all
Overview
Version │ 2026.4.26
OS │ linux 6.17.0-22-generic (x64)
Node │ 22.22.2
Config │ ~/.openclaw/openclaw.json
Dashboard │ http://127.0.0.1:18789/
Tailscale exposure │ serve · unknown · ainchor.tailf5ebd7.ts.net · https://ainchor.tailf5ebd7.ts.net
Channel │ stable (default)
Update │ pnpm · up to date · npm latest 2026.4.26
Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 29ms · auth token · AInchor (192.168.1.5) app 2026.4.26 linux 6.17.0-22-generic
Security │ Run: openclaw security audit --deep
Gateway self │ unknown
Gateway service │ systemd installed · enabled · running (pid 1704, state active)
Node service │ systemd not installed
Agents │ 1 total · 0 bootstrapping · 0 active · 5 sessions
Secrets │ none
Agents
main │ ABSENT │ 5 │ 20m ago │ ~/.openclaw/agents/main/sessions/sessions.json
Diagnosis (read-only)
Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/michael/.openclaw/openclaw.json
Bind: loopback
✓ Config: /home/michael/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.
- pid 1704 michael: openclaw-gateway (127.0.0.1:18789)
- Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale exposure: serve · daemon unknown · ainchor.tailf5ebd7.ts.net
https: https://ainchor.tailf5ebd7.ts.net
✓ Skills: 12 eligible · 0 missing · /home/michael/.openclaw/workspace
✓ Plugin compatibility (none)
Gateway restart attempts (tail): /home/michael/.openclaw/logs/gateway-restart.log
[2026-04-25T01:40:13Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-25T01:40:13Z] openclaw restart done source=update
✓ Channel issues (none)
This output is actually reassuring: the gateway is healthy.
Two bits that look scary but aren’t the problem:
main │ ABSENTmeans bootstrap file absent, not “agent missing”.Port 18789 already in useis just the runningopenclaw-gatewayprocess owning its own port.
I’d try session recovery before rollback:
/new
or:
/reset
Send that as a standalone message in the wedged Dashboard/chat session, then hard-refresh the Dashboard.
If it still wedges, tail logs while sending one test message:
openclaw logs --follow
If logs mention devices/pending.json / Unexpected end of JSON input, run:
mv ~/.openclaw/devices/pending.json ~/.openclaw/devices/pending.json.bak
openclaw gateway restart
If you still want to revert, previous stable is 2026.4.25:
openclaw update --tag 2026.4.25 --yes
openclaw doctor
openclaw gateway restart
Fallback if updater won’t cooperate:
pnpm add -g openclaw@2026.4.25
openclaw doctor
openclaw gateway restart
Log file: /tmp/openclaw/openclaw-2026-04-29.log
19:03:00+00:00 info gateway {"subsystem":"gateway"} loading configuration…
19:03:01+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
19:03:01+00:00 info gateway {"subsystem":"gateway"} starting...
19:03:03+00:00 error (node:1704) [DEP0040] DeprecationWarning: The punycode module is deprecated. Please use a userland alternative instead.
(Use node --trace-deprecation ... to show where the warning was created)
19:03:03+00:00 info gateway {"subsystem":"gateway"} starting HTTP server...
19:03:03+00:00 info gateway/canvas {"subsystem":"gateway/canvas"} canvas host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /home/michael/.openclaw/canvas)
19:03:03+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
19:03:03+00:00 info gateway {"subsystem":"gateway"} agent model: openai-codex/gpt-5.4
19:03:03+00:00 info gateway {"subsystem":"gateway"} http server listening (1 plugin: telegram; 2.6s)
19:03:03+00:00 info gateway {"subsystem":"gateway"} log file: /tmp/openclaw/openclaw-2026-04-29.log
19:03:03+00:00 info gateway {"subsystem":"gateway"} starting channels and sidecars...
19:03:03+00:00 info gateway/tailscale {"subsystem":"gateway/tailscale"} serve enabled: https://ainchor.tailf5ebd7.ts.net/ (WS via wss://ainchor.tailf5ebd7.ts.net)
19:03:03+00:00 info gateway/hooks {"subsystem":"gateway/hooks"} loaded 4 internal hook handlers
19:03:03+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
19:03:08+00:00 warn gateway/model-pricing {"subsystem":"gateway/model-pricing"} OpenRouter pricing fetch failed: TypeError: fetch failed
19:03:27+00:00 info gateway {"subsystem":"gateway"} gateway ready
19:03:28+00:00 info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
Those logs look clean. The scary lines are basically noise:
punycodedeprecation: harmless Node warning- Telegram IPv4 fallback: network fallback, not fatal
- OpenRouter pricing fetch failed: annoying, but not gateway-breaking
gateway ready+ heartbeat started = gateway booted fine
So I’d stop thinking rollback for the moment. We need to see what happens when you send a message.
Please run this, then send one test message in the wedged dashboard/session:
openclaw logs --follow
If nothing new appears, it’s likely Dashboard/browser/auth/Tailscale routing, not the agent. Try the local URL directly on that machine:
http://127.0.0.1:18789/
Then hard refresh and reconnect with the gateway token if prompted.
If log lines do appear and the agent starts but stalls, send /new as a standalone message first. That should clear a bad session without changing versions.
Rollback should be the last move here; the gateway itself is healthy.
19:03:28+00:00 info cron {"module":"cron","storePath":"/home/michael/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":3,"nextWakeAtMs":1777500000000} cron: started
19:03:28+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
19:03:28+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=67d97272-43e3-4052-a16d-b27abb784d71 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.4.26
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.subscribe 139ms conn=67d97272…4d71 id=fd787fbb…1d7f
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ agent.identity.get 141ms conn=67d97272…4d71 id=fc4b04b8…d0fd
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ agents.list 142ms conn=67d97272…4d71 id=c982def7…6788
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 143ms cached=true conn=67d97272…4d71 id=bad0d13c…1b8f
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 179ms conn=67d97272…4d71 id=72edcf19…add1
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 186ms conn=67d97272…4d71 id=fc5467ca…8985
That’s the Dashboard connecting successfully — good sign. It’s loading sessions/history fine.
What’s missing is the log line for an actual message send / agent turn. While openclaw logs --follow is running, send one test message in the Dashboard.
Then:
- If no new log lines appear: the UI isn’t submitting the turn. Hard refresh, reconnect via
http://127.0.0.1:18789/, select/create a session, then try/new. - If new lines appear and it stalls after the agent/model starts: this is likely model/session-side, not gateway-side. Try
/new; if still stuck, run:
openclaw models status
Given the logs so far, I still wouldn’t roll back yet — gateway + webchat are alive.
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 282ms conn=67d97272…4d71 id=72880725…7c92
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 314ms conn=67d97272…4d71 id=91e18846…4c01
19:03:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 316ms conn=67d97272…4d71 id=135346a1…6b3c
19:03:31+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
19:03:31+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} [default] starting provider
19:03:37+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ models.list 8292ms conn=67d97272…4d71 id=19a5d24f…7b89
19:03:47+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 56 commands visible.
19:03:47+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 10770ms conn=67d97272…4d71 id=48e3a822…0e22
19:03:56+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)
19:04:30+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram deleteWebhook failed: Network request for 'deleteWebhook' failed!
19:04:30+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.41s.
19:04:30+00:00 warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 13473 chars (limit 12000); truncating in injected context (sessionKey=temp:slug-generator)
19:04:31+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-29-cron-config.md
19:04:36+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} Telegram menu text exceeded the conservative 5700-character payload budget; shortening descriptions to keep 56 commands visible.
19:04:36+00:00 warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 13473 chars (limit 12000); truncating in injected context (sessionKey=agent:main:main)
19:04:45+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"56b44477-fd90-458b-9493-4d4d0aca68e0","isError":true,"error":"One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.","failoverReason":null,"model":"gpt-5.4","provider":"openai-codex","rawErrorPreview":"One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.","rawErrorHash":"sha256:f4df43227553","providerRuntimeFailureKind":"unclassified"} embedded run agent end
19:24:35+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 105ms conn=345c738b…ecef id=f7352ce9…3ef2
19:28:48+00:00 warn agent/embedded {"subsystem":"agent/embedded"} session file repaired: rewrote 1 assistant message(s), dropped 1 blank user message(s) (70adef03-593d-4b9e-80fe-7019f7ac592d.jsonl)
19:33:23+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-29-heartbeat-poll.md
19:33:37+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":
["error_handling","lifecycle","agent_end","assistant_error"],"runId":"89a1f551-4848-4f77-9fb7-d2383fba24b1","isError":true,"error":"One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.","failoverReason":null,"model":"gpt-5.4","provider":"openai-codex","rawErrorPreview":"One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.","rawErrorHash":"sha256:f4df43227553","providerRuntimeFailureKind":"unclassified"} embedded run agent end
19:34:35+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-29-1534.md
19:34:48+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"da90d97b-5d0d-4f38-bb58-b98328afcd7a","isError":true,"error":"One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.","failoverReason":null,"model":"gpt-5.4","provider":"openai-codex","rawErrorPreview":"One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.","rawErrorHash":"sha256:f4df43227553","providerRuntimeFailureKind":"unclassified"} embedded run agent end
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/michael/.openclaw/openclaw.json
Bind: loopback
This points more to outbound network/Telegram trouble, not a bad gateway update.
These are the key lines:
ETIMEDOUT, ENETUNREACH
telegram deleteWebhook failed
OpenRouter pricing fetch failed
So the host is having trouble reaching external services. Rollback probably won’t fix that.
Next checks:
openclaw channels status --probe
openclaw models status
If you’re not actively using Telegram while testing Dashboard, temporarily disable it to remove the retry noise:
openclaw config set channels.telegram.enabled false
openclaw gateway restart
Then test Dashboard again and send /new.
Re-enable later with:
openclaw config set channels.telegram.enabled true
openclaw gateway restart
If Telegram is your main channel, the fix is network/proxy/DNS/IPv6 egress to Telegram’s API, not session rollback. Docs: https://docs.openclaw.ai/channels/telegram#troubleshooting
Aha — this is the real failure, not the gateway:
One of "input" or "previous_response_id" ... must be provided
session file repaired ... dropped 1 blank user message
So the agent/model run is getting an empty/bad turn. The gateway is fine.
Try in this order:
- Start a clean session:
/new
-
If that doesn’t submit from Dashboard, use the Dashboard “new session” flow / hard refresh, then send a normal test message.
-
Since logs also show
temp:slug-generator, check cron isn’t firing an empty prompt:
openclaw cron list
openclaw cron show <job-id>
To isolate cron temporarily:
openclaw config set cron.enabled false
openclaw gateway restart
- If clean session still fails, switch away from the current
openai-codexmodel route using/modelor the Dashboard picker, then test again.openclaw models statusshould show what’s healthy.
The MEMORY.md truncating warning is not fatal.
If /new + disabling cron + model switch still produces that exact empty-input error, I’d treat it as a 2026.4.26 bug and either roll back to 2026.4.25 or file a GitHub issue with that log snippet. Docs: https://docs.openclaw.ai/automation/cron-jobs
Yep, now we’ve got a much clearer signal.
Two things changed:
- Gateway is now not reachable → first recover the service.
- The agent is failing on
openai-codex/gpt-5.4with an empty-input style error. That model route looks suspicious; current docs point Codex OAuth users atopenai-codex/gpt-5.5.
Do this from terminal:
openclaw gateway restart
openclaw gateway status
Once reachable, switch the default model:
openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5
openclaw gateway restart
Then start clean in Dashboard/chat:
/new
If it still repeats the same error, I’d rollback to previous stable:
openclaw update --tag 2026.4.25 --yes
openclaw doctor
openclaw gateway restart
And if rollback fixes it, that log snippet is GitHub-issue-worthy: https://github.com/openclaw/openclaw/issues
Model docs: https://docs.openclaw.ai/providers/openai
Hard reset seemed to get it back, I'll have the agent run health checks from here.
Nice, glad it came back 🦐
Good follow-up checks:
openclaw status --all
openclaw health --verbose
openclaw channels status --probe
openclaw models status
If it stays fixed, please mark the solution so Answer Overflow indexes it for the next person: right-click the solution message → Apps → ✅ Mark Solution.
yes
Awesome — glad it’s recovered 🎉
If this thread solved it, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed for future folks.