#How to restore previous version

1 messages · Page 1 of 1 (latest)

crisp drum
#

I ran the latest update, and the gateway seems to be having issues. I ran doctor fixes, and the dashboard cleared to the ui, but the session seems wedged. Is there a fix, or what is the best way to revert back to the previous version?

#

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

paper parrotBOT
#

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:

#

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>
crisp drum
#

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)
paper parrotBOT
#

This output is actually reassuring: the gateway is healthy.

Two bits that look scary but aren’t the problem:

  • main │ ABSENT means bootstrap file absent, not “agent missing”.
  • Port 18789 already in use is just the running openclaw-gateway process 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
crisp drum
#

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

paper parrotBOT
#

Those logs look clean. The scary lines are basically noise:

  • punycode deprecation: 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.

crisp drum
#

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

paper parrotBOT
#

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.

crisp drum
#

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

paper parrotBOT
#

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:

#

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:

  1. Start a clean session:
/new
#
  1. If that doesn’t submit from Dashboard, use the Dashboard “new session” flow / hard refresh, then send a normal test message.

  2. 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
  1. If clean session still fails, switch away from the current openai-codex model route using /model or the Dashboard picker, then test again. openclaw models status should 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:

  1. Gateway is now not reachable → first recover the service.
  2. The agent is failing on openai-codex/gpt-5.4 with an empty-input style error. That model route looks suspicious; current docs point Codex OAuth users at openai-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
crisp drum
#

Hard reset seemed to get it back, I'll have the agent run health checks from here.

paper parrotBOT
#

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.

crisp drum
#

yes

paper parrotBOT
#

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.