Session chat issues after updating to 2026.5.12

[craggy spindle]

After updating to 2026.5.12 a few things are happening

• openclaw doctor says not a git repo, run update -- but already have
• my chats are timing out. I'm getting "This response is taking longer than expected. Send another message to continue". Both on CLI chat and via the web dashboard

[vital berry]

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

[hexed plank]

For the first bullet: that “not a git repo, run update” path is usually not saying your workspace is broken. In current source, doctor probes the OpenClaw install root with git; if your install is npm/pnpm/global rather than a source checkout, it prints the package-manager update hint. openclaw update is still the right updater for that install type. Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/gateway/doctor

For the chat timeouts, since it happens in both CLI chat and the dashboard, I’d treat it as a gateway/agent-run issue, not just a web UI issue. Quick safe triage:

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

Then, in a fresh chat/session, try a tiny prompt like “hi”. If a fresh session works but the existing one times out, it points toward stale/corrupt session history after the update; use /new or /reset for that chat. The FAQ calls this out for stale session/history cases: https://docs.openclaw.ai/help/faq#sessions-and-multiple-chats

If even a brand-new session times out, please paste the redacted output from openclaw status --all plus the log lines from one failed tiny prompt. Look especially for provider/auth timeout, model/tool-schema errors, or session lock/state warnings. If it’s reproducible on 2026.5.12 after restart + fresh session, that’s probably worth a GitHub issue with those logs: https://github.com/openclaw/openclaw/issues

[craggy spindle]

Overview
┌────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value
├────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.5.12
│ OS │ macos 26.4.1 (x64)
│ Node │ 24.15.0
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale exposure │ off
│ Channel │ stable (default)
│ Update │ pnpm · up to date · npm latest 2026.5.12
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 104ms · auth token · MBP.local (192.168.1.142) app 2026.5.12 macos 26.4.1 │
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ unknown
│ Gateway service │ LaunchAgent installed · loaded · running (pid 47922, state active)
│ Node service │ LaunchAgent not installed
│ Agents │ 1 total · 0 bootstrapping · 1 active · 2 sessions
│ Secrets │ none
└────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail e

[hexed plank]

Thanks, that status is useful. Node 24.15.0 is not automatically suspicious here; current docs require Node >=22, and the updater explicitly allows Node 24. The macOS LaunchAgent piece is more worth checking because version-managed Node paths can get stale after upgrades.

Two next steps I’d do:

openclaw doctor --repair
openclaw gateway restart

Then start a brand-new session and send only “hi”:

openclaw chat --new

If that still times out, run this while sending the tiny prompt and paste the relevant failure block:

[hexed plank]

openclaw logs --follow

The snippet you posted shows the gateway is reachable, loaded, and on 2026.5.12, so the missing clue is whether the agent run is hanging on provider auth/model transport, a session-store issue, or a service/runtime path mismatch. doctor --repair should also surface/rewrite a bad LaunchAgent entrypoint if that’s involved. Docs refs: https://docs.openclaw.ai/help/faq#first-60-seconds-if-something-is-broken and https://docs.openclaw.ai/gateway/doctor

[craggy spindle]

Diagnosis (read-only)

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

✓ Config: /Users/agent/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none

Gateway last log line:
2026-05-15T12:21:03.355+02:00 [ws] ⇄ res ✓ health 539ms conn=4229b24d…5435 id=eb79d865…8f81
✓ Port 18789
Detected OpenClaw Gateway listener on the configured port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 11 eligible · 0 missing · /Users/agent/.openclaw/workspace
✓ Plugin compatibility (none)

[hexed plank]

This still looks healthy at the gateway layer: config loads, port is listening, WS health responds, skills are present. The Tailscale exposure: off · daemon unknown line is not relevant unless you expect Tailscale Serve.

At this point the useful evidence is the agent run itself. Please do this exact loop:

openclaw logs --follow

In another terminal:

openclaw chat --new

Send just:

[hexed plank]

hi

Then paste the log block from when that prompt starts until it times out/errors. Also run:

openclaw models status

Given gateway health is OK, I’d expect the logs to show one of: provider/auth cooldown, model transport failure, stale session/history handling, or a LaunchAgent/runtime path issue. If you installed Node/OpenClaw through nvm/pnpm, openclaw doctor --repair is still worth running because macOS LaunchAgents do not load shell init files and can keep pointing at old version-manager paths after upgrades.

[craggy spindle]

2026-05-15T12:13:48.882+02:00 [ws] ⇄ res ✓ commands.list 85ms conn=2bb1e42f…da56 id=8478f28f…9e0d
2026-05-15T12:13:48.884+02:00 [ws] ⇄ res ✓ models.list 87ms conn=2bb1e42f…da56 id=fe259c66…fd90
2026-05-15T12:13:48.888+02:00 [ws] ⇄ res ✓ sessions.list 91ms conn=2bb1e42f…da56 id=b5411f59…f39a
2026-05-15T12:13:48.898+02:00 [ws] ⇄ res ✓ chat.history 101ms conn=2bb1e42f…da56 id=c08c1608…dc25
2026-05-15T12:16:54.588+02:00 [reload] config change detected; evaluating reload (wizard.lastRunAt, wizard.lastRunCommand, meta.lastTouchedAt)
2026-05-15T12:19:52.270+02:00 [reload] config change detected; evaluating reload (wizard.lastRunAt, meta.lastTouchedAt)
2026-05-15T12:20:11.360+02:00 [reload] config change detected; evaluating reload (wizard.lastRunAt, meta.lastTouchedAt)
2026-05-15T12:20:38.888+02:00 [ws] ⇄ res ✓ channels.status 677ms conn=6ce505e2…bb42 id=99f86803…2d1f
2026-05-15T12:21:03.355+02:00 [ws] ⇄ res ✓ health 539ms conn=4229b24d…5435 id=eb79d865…8f81

Gateway restart attempts (tail): /Users/agent/.openclaw/logs/gateway-restart.log
[2026-05-10T21:21:11Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/502/ai.openclaw.gateway waitPid=28274
[2026-05-10T21:21:16Z] openclaw restart done source=launchd-handoff mode=kickstart
[2026-05-10T21:52:51Z] openclaw restart attempt source=launchd-handoff mode=kickstart target=gui/502/ai.openclaw.gateway waitPid=31144
[2026-05-10T21:52:56Z] openclaw restart done source=launchd-handoff mode=kickstart
✓ Channel issues (none)

[hexed plank]

Those lines are all successful dashboard/control RPCs; I don’t see a chat.send, agent, provider, or error line in that slice. The config reload lines are probably from doctor/wizard touching metadata and don’t explain the timeout by themselves.

Can you capture from just before submitting the tiny prompt? The useful block should include the request that starts the run, not just commands.list/models.list/sessions.list/chat.history.

Try:

openclaw logs --follow --json

Then send hi in openclaw chat --new. If nothing at all appears in logs when you submit the prompt, that’s a different clue: the CLI/dashboard is not successfully dispatching the chat request to the gateway, despite health/list/history working.

Also paste openclaw models status when you can; if the run reaches the model layer, that’s where I’d expect the actual failure to show up.

[hexed plank]

That restart tail is from May 10, so it probably isn’t related to today’s 2026.5.12 timeout. “Channel issues none” is also expected here because CLI/dashboard chat does not depend on Discord/Telegram/etc channel health.

The thread is at the point where generic health checks are exhausted. Please grab one live failing run:

openclaw logs --follow --json

Then in another terminal:

openclaw chat --new

Send hi, wait for the timeout, and paste the log lines produced during that exact window. Also paste:

[hexed plank]

openclaw models status

Without the live run log, all we can say is “gateway/control plane works”; the broken piece is likely after dispatch, in the agent/model/session path.

[craggy spindle]

openclaw chat --new (new is not recognized)

[hexed plank]

You’re right, sorry — openclaw chat --new is stale/wrong.

Current flow is:

openclaw chat

Then send this as the first message inside the chat:

/new hi

or just:

[hexed plank]

/new

Then send:

hi

Docs/source confirm openclaw chat is the TUI entrypoint and /new / /reset are in-chat session commands: https://docs.openclaw.ai/web/tui and https://docs.openclaw.ai/tools/slash-commands

Keep openclaw logs --follow --json running while you do that so we capture the actual failing run.

[craggy spindle]

{"type":"log","time":"2026-05-15T12:27:28.267+02:00","level":"warn","subsystem":"skills","message":"{"subsystem":"skills"} {"source":"agents-skills-personal","rootDir":"/Users/agent/.agents/skills","rootRealPath":"/Users/agent/.agents/skills","path":"/Users/agent/.agents/skills/test-skill","realPath":"/Users/agent/.local/share/test-skill/skills/test-skill","reason":"symlink-escape"} Skipping escaped skill path outside its configured root.","raw":"{"0":"{\"subsystem\":\"skills\"}","1":{"source":"agents-skills-personal","rootDir":"/Users/agent/.agents/skills","rootRealPath":"/Users/agent/.agents/skills","path":"/Users/agent/.agents/skills/test-skill","realPath":"/Users/agent/.local/share/test-skill/skills/test-skill","reason":"symlink-escape"},"2":"Skipping escaped skill path outside its configured root.","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"skills\"}","parentNames":["openclaw"],"date":"2026-05-15T10:27:28.267Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:176:51","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:176","fileColumn":"51","fileLine":"176","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:176","method":"logToFile"}},"time":"2026-05-15T12:27:28.267+02:00","hostname":"MBP.local","message":"Skipping escaped skill path outside its configured root."}"}

[hexed plank]

That warning is real, but it’s probably not the chat-timeout root cause by itself. It means OpenClaw found a skill entry here:

/Users/agent/.agents/skills/test-skill

…but it resolves through a symlink to:

/Users/agent/.local/share/test-skill/skills/test-skill

Because that target is outside the configured skills root, OpenClaw skips it for safety.

To clean that up, either remove that test symlink, or configure the real parent as an extra skills directory if you actually want to load it. Since it says test-skill, I’d first move/remove that symlink and restart:

[hexed plank]

ls -la /Users/agent/.agents/skills/test-skill
trash /Users/agent/.agents/skills/test-skill
openclaw gateway restart

Then retry openclaw chat → /new hi.

If it still times out, we still need the next log lines after this warning. This line only says skill discovery skipped one escaped path; it doesn’t show the agent/model run failing yet.

[craggy spindle]

will paste a few log messages, continue when i say "DONE" please

{"type":"log","time":"2026-05-15T12:29:46.839+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 347ms conn=02f1aac3…0995 id=67fd13a9…0a61","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✓ logs.tail 347ms conn=02f1aac3…0995 id=67fd13a9…0a61","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:46.838Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:46.839+02:00","hostname":"MBP.local","message":"⇄ res ✓ logs.tail 347ms conn=02f1aac3…0995 id=67fd13a9…0a61","traceId":"6c9e8ebd9c9bf81ba92c0709133219c4","spanId":"04529ae020cb35ff","traceFlags":"01"}"}

[hexed plank]

Got it. I’ll wait for DONE before interpreting the log batch.

[craggy spindle]

{"type":"log","time":"2026-05-15T12:29:49.086+02:00","level":"warn","subsystem":"main-session-restart-recovery","message":"{"subsystem":"main-session-restart-recovery"} marked interrupted main session failed: agent:main:main (transcript tail is not resumable)","raw":"{"0":"{\"subsystem\":\"main-session-restart-recovery\"}","1":"marked interrupted main session failed: agent:main:main (transcript tail is not resumable)","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"main-session-restart-recovery\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.085Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.086+02:00","hostname":"MBP.local","message":"marked interrupted main session failed: agent:main:main (transcript tail is not resumable)"}"}

{"type":"log","time":"2026-05-15T12:29:49.088+02:00","level":"info","subsystem":"main-session-restart-recovery","message":"{"subsystem":"main-session-restart-recovery"} main-session restart recovery complete: recovered=0 failed=1 skipped=0","raw":"{"0":"{\"subsystem\":\"main-session-restart-recovery\"}","1":"main-session restart recovery complete: recovered=0 failed=1 skipped=0","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"main-session-restart-recovery\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.088Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.088+02:00","hostname":"MBP.local","message":"main-session restart recovery complete: recovered=0 failed=1 skipped=0"}"}

{"type":"log","time":"2026-05-15T12:29:49.649+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} webchat connected conn=b3b8909d-d563-4290-a3f5-b712dd650f17 remote=127.0.0.1 client=openclaw-control-ui webchat vcontrol-ui","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"webchat connected conn=b3b8909d-d563-4290-a3f5-b712dd650f17 remote=127.0.0.1 client=openclaw-control-ui webchat vcontrol-ui","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.649Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.649+02:00","hostname":"MBP.local","message":"webchat connected conn=b3b8909d-d563-4290-a3f5-b712dd650f17 remote=127.0.0.1 client=openclaw-control-ui webchat vcontrol-ui","traceId":"e26d2c594092a458ba5dfe0ce5eb4553","spanId":"dcbc9601fb1d0ed0","traceFlags":"01"}"}

{"type":"log","time":"2026-05-15T12:29:49.782+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✓ agents.list 52ms conn=b3b8909d…0f17 id=29842d37…afc1","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✓ agents.list 52ms conn=b3b8909d…0f17 id=29842d37…afc1","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.782Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.782+02:00","hostname":"MBP.local","message":"⇄ res ✓ agents.list 52ms conn=b3b8909d…0f17 id=29842d37…afc1","traceId":"e67d53f5a2369ed605ce88c81dbca133","spanId":"cfd4b0973f251a67","traceFlags":"01"}"}

{"type":"log","time":"2026-05-15T12:29:49.899+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 74ms conn=b3b8909d…0f17 id=a7c9e447…02f3","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✓ commands.list 74ms conn=b3b8909d…0f17 id=a7c9e447…02f3","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.898Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.899+02:00","hostname":"MBP.local","message":"⇄ res ✓ commands.list 74ms conn=b3b8909d…0f17 id=a7c9e447…02f3","traceId":"22650e8bf362e4b8952df5be8cdfd7af","spanId":"e3268100fd627eaa","traceFlags":"01"}"}

{"type":"log","time":"2026-05-15T12:29:49.929+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 104ms conn=b3b8909d…0f17 id=98f3dc94…03f7","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✓ chat.history 104ms conn=b3b8909d…0f17 id=98f3dc94…03f7","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.928Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.929+02:00","hostname":"MBP.local","message":"⇄ res ✓ chat.history 104ms conn=b3b8909d…0f17 id=98f3dc94…03f7","traceId":"edf0a8fdf04a6dfd9f0280394522fa37","spanId":"9bbcddd0e567b7c7","traceFlags":"01"}"}

{"type":"log","time":"2026-05-15T12:29:49.939+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✓ models.list 115ms conn=b3b8909d…0f17 id=3380d4ac…ffa1","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✓ models.list 115ms conn=b3b8909d…0f17 id=3380d4ac…ffa1","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.939Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.939+02:00","hostname":"MBP.local","message":"⇄ res ✓ models.list 115ms conn=b3b8909d…0f17 id=3380d4ac…ffa1","traceId":"69694900c67e591b568ba222fe27cf05","spanId":"9030961dcf8b9a21","traceFlags":"01"}"}

{"type":"log","time":"2026-05-15T12:29:49.948+02:00","level":"info","subsystem":"gateway/ws","message":"{"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 123ms conn=b3b8909d…0f17 id=fc29f61a…0c95","raw":"{"0":"{\"subsystem\":\"gateway/ws\"}","1":"⇄ res ✓ sessions.list 123ms conn=b3b8909d…0f17 id=fc29f61a…0c95","_meta":{"runtime":"node","runtimeVersion":"24.15.0","hostname":"unknown","name":"{\"subsystem\":\"gateway/ws\"}","parentNames":["openclaw"],"date":"2026-05-15T10:29:49.947Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177:14","fileName":"subsystem-DLRoKDlF.js","fileNameWithLine":"subsystem-DLRoKDlF.js:177","fileColumn":"14","fileLine":"177","filePath":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js","filePathWithLine":"/usr/local/Cellar/node@24/24.15.0/lib/node_modules/openclaw/dist/subsystem-DLRoKDlF.js:177","method":"logToFile"}},"time":"2026-05-15T12:29:49.948+02:00","hostname":"MBP.local","message":"⇄ res ✓ sessions.list 123ms conn=b3b8909d…0f17 id=fc29f61a…0c95","traceId":"5d259913986e4296312af79d881f4fd5","spanId":"3cd3f33ff6ee15aa","traceFlags":"01"}"}

DONE

[hexed plank]

Thanks. This batch has one meaningful warning:

main-session-restart-recovery: marked interrupted main session failed: agent:main:main (transcript tail is not resumable)
main-session restart recovery complete: recovered=0 failed=1 skipped=0

That means the gateway found an interrupted main session after restart/update and could not resume its transcript tail. That lines up with “session chat after update” much more than the skill symlink warning.

The rest of the batch is just the dashboard/control UI connecting and loading lists/history/models successfully. I still don’t see a chat.send, agent, or provider/model error in this pasted set, so either the send happened after the pasted window, or the UI/CLI never got as far as dispatching the chat run.

Next move:

openclaw chat

[hexed plank]

Then type exactly:

/new hi

If that works, the old interrupted main session was the problem.

If /new hi still times out, run:

openclaw doctor --repair
openclaw gateway restart

and retry once. If it still fails after that, I’d package this as a bug because 2026.5.12 is failing to recover or bypass a non-resumable main transcript. Best artifact for a GitHub issue is:

[hexed plank]

openclaw gateway diagnostics export

Issue link: https://github.com/openclaw/openclaw/issues

[craggy spindle]

can i just remove/reset all old sessions and start anew

[hexed plank]

Yes. If you only want to discard conversation/session state and keep config/auth/workspace, don’t use openclaw reset yet; that’s a broader reset.

Safest order:

1. Try the normal in-chat reset first:

/new

2. If you want to wipe all stored sessions for the main agent, stop the gateway and move the sessions folder aside:

openclaw gateway stop
mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup.$(date +%Y%m%d-%H%M%S)
openclaw gateway start

[hexed plank]

openclaw doctor

That should preserve config, auth profiles, credentials, skills, and workspace memory. It only removes/moves conversation history + session metadata for agent main.

If your agent id is not main, check:

ls ~/.openclaw/agents

Docs for the paths: https://docs.openclaw.ai/help/faq#where-does-openclaw-store-its-data

If it works after moving sessions aside, keep the backup for a bit, then delete it later once you’re comfortable. If it still fails with a totally fresh sessions dir, that’s strong evidence for a 2026.5.12 bug outside session history.

[craggy spindle]

A weird tell is that openclaw chat takes a long time to start

[hexed plank]

That is a useful tell. openclaw chat startup should mostly be: start CLI/TUI, connect to gateway, then load agents.list, commands.list, models.list, sessions.list, and chat.history. In the logs you pasted, those gateway calls were fast once connected, so if the delay is before the UI appears it may be local CLI startup or session/history scanning.

Quick way to narrow it:

time openclaw chat

Quit as soon as it opens, then compare after moving sessions aside:

openclaw gateway stop
mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup.$(date +%Y%m%d-%H%M%S)
openclaw gateway start
time openclaw chat

[hexed plank]

If chat startup becomes normal, the old sessions/transcript store was the slowdown and likely also tied to the non-resumable main-session warning.

If it’s still slow with a fresh sessions dir, check whether the CLI itself is slow:

time openclaw --version
time openclaw status

If even openclaw --version is slow, that points away from sessions and toward the pnpm/Homebrew Node/global install path or shell/env startup.

[craggy spindle]

can i not just remove the old sessions transcripts

[hexed plank]

Yes, you can. I’d move them aside rather than delete them outright, because if this isn’t the root cause you can put them back.

I would move the whole sessions directory, not just transcript files. If you delete only transcripts while leaving sessions.json, you can leave metadata pointing at missing files.

openclaw gateway stop
mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.backup.$(date +%Y%m%d-%H%M%S)
openclaw gateway start

Then open chat and try:

/new hi

This preserves config, auth, credentials, skills, and workspace/memory. It only resets conversation history/session state for the main agent. If your agent id is different, check with:

[hexed plank]

ls ~/.openclaw/agents

If you prefer using Trash on macOS instead of a backup folder:

openclaw gateway stop
trash ~/.openclaw/agents/main/sessions
openclaw gateway start

But the mv ... sessions.backup... route is the cleanest for debugging.

[craggy spindle]

openclaw chat still freezes for >10s

[hexed plank]

If sessions are already moved aside and openclaw chat still freezes for >10s, I’d stop focusing on old transcripts and measure CLI startup.

Run these and paste the timings:

time openclaw --version
time openclaw status
OPENCLAW_DEBUG_TIMING=1 openclaw chat

The debug timing output should show which startup phase burns the time. There is a known-ish class of macOS issues where launch/service or version-manager paths are weird after updates, but your pasted logs showed Homebrew Node under /usr/local/Cellar/node@24/24.15.0/..., so we need timing before guessing.

Also run:

openclaw doctor --repair

[hexed plank]

openclaw gateway restart

If openclaw --version itself takes ~10s, that’s local CLI/package startup. If --version is fast but status/chat is slow, it’s gateway connect or startup RPCs. If debug timing points at chat.history/sessions even after moving sessions aside, that’s useful bug evidence.

[craggy spindle]

openclaw --version < 1.s
openclaw status 4s
openclaw chat >15s

[hexed plank]

Good, that rules out general Node/package startup. The slow part is after the CLI starts: gateway/status RPCs or TUI initialization.

Next most useful thing is the phase breakdown:

OPENCLAW_DEBUG_TIMING=1 openclaw chat

Paste the timing lines it prints before/while the UI appears. If it hangs before printing anything useful, try JSON mode and redirect it:

OPENCLAW_DEBUG_TIMING=json openclaw chat 2> /tmp/openclaw-chat-timing.jsonl

Also, since status is 4s, run the lighter checks separately:

[hexed plank]

time openclaw gateway status
time openclaw health --verbose
time openclaw models status

My read so far:

• openclaw --version <1s = local CLI/package startup is fine.
• status 4s = gateway health/model/session checks are a bit slow but not frozen.
• chat >15s = likely TUI startup waiting on one of agents.list, models.list, sessions.list, or chat.history.

If the debug timing shows chat.history or sessions.list taking the time even after moving ~/.openclaw/agents/main/sessions aside, that’s strong bug-report material for 2026.5.12.

[craggy spindle]

is it ok to use openai/gpt-5.5 as model even in this new version where codex is a default?

[hexed plank]

Short version: use the prefix that matches your auth/route.

Per the current OpenAI docs:

• openai-codex/... = Codex subscription/OAuth through the default PI runner.
• openai/... = direct OpenAI API-key route, unless you explicitly force the Codex app-server harness.

So if you mean “use my Codex subscription / the new Codex default path”, prefer:

openclaw config set agents.defaults.model.primary openai-codex/gpt-5.5

If you set openai/gpt-5.5 without the Codex app-server harness, OpenClaw treats that as the direct OpenAI API route, and the docs say direct API-key access depends on OpenAI enabling that model on the public API.

Docs: https://docs.openclaw.ai/providers/openai and model config overview: https://docs.openclaw.ai/concepts/models

[hexed plank]

For “what’s best today” model picks, #models is still the better place because availability/quality changes fast.

[craggy spindle]

will do openclaw reset config+creds+sessions
and setup up from scratch

[hexed plank]

That’s reasonable if you’re okay re-onboarding auth and config from scratch.

Before you do it, I’d make one backup snapshot so you can recover anything important:

cp -a ~/.openclaw ~/.openclaw.backup.$(date +%Y%m%d-%H%M%S)

Then the broad reset path from the docs is:

openclaw reset
openclaw onboard --install-daemon

If you want it fully non-interactive/destructive:

[hexed plank]

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

That will wipe more than sessions: config, auth/credentials, state, etc. Your workspace/memory can matter too, so double-check the reset prompt scope before confirming. Docs: https://docs.openclaw.ai/help/faq#how-do-i-completely-reset-openclaw-but-keep-it-installed

After onboarding, first test with a tiny openclaw chat → hi before restoring any old files. If the fresh setup is still slow, that strongly points to an install/runtime bug rather than state corruption.

[craggy spindle]

I reinstalled. Still same issue. Times out

[hexed plank]

Fresh reinstall + same timeout means this is very unlikely to be old sessions/transcripts now. I’d treat it as either model/auth routing or a 2026.5.12 runtime bug.

Please check two things:

openclaw models status
openclaw config get agents.defaults.model

If you’re using Codex subscription auth, make sure the model route is openai-codex/..., not plain openai/.... Plain openai/... is the direct API-key route unless you explicitly configured the Codex app-server harness. Docs: https://docs.openclaw.ai/providers/openai

Then capture the failing tiny prompt:

openclaw logs --follow --json

[hexed plank]

In another terminal, run openclaw chat and send just hi. If it times out after a clean reinstall, please file this with a diagnostics export:

openclaw gateway diagnostics export

Issue link: https://github.com/openclaw/openclaw/issues

At this point the important artifact is the log line where the agent run starts/fails; the gateway health/control RPCs we saw earlier were fine.

[craggy spindle]

can i try an older version to see if that works differently?

[hexed plank]

Yes. That’s a good A/B test now that a reinstall didn’t fix it.

The previous stable before 2026.5.12 on npm is 2026.5.7 (there are 2026.5.10-beta.* builds too, but I’d test stable first).

Try:

openclaw update --tag 2026.5.7
openclaw --version
openclaw doctor
openclaw gateway restart

If openclaw update --tag 2026.5.7 doesn’t cooperate with your install, use the same package manager path directly:

[hexed plank]

pnpm add -g openclaw@2026.5.7
openclaw doctor
openclaw gateway restart

Then test:

time openclaw chat

To go back to current stable:

openclaw update --channel stable

[hexed plank]

or:

pnpm add -g openclaw@latest
openclaw doctor
openclaw gateway restart

Docs rollback section: https://docs.openclaw.ai/install/updating#rollback

If 2026.5.7 works and 2026.5.12 times out on the same fresh config/model auth, that’s a very clean regression signal for a GitHub issue.

[craggy spindle]

if i uninstall can i install openclaw@2026.5.7 directly?

[hexed plank]

Yes. You can install that version directly; uninstall first is optional but can make the test cleaner.

Since your status said the install type was pnpm, I’d do:

openclaw gateway stop
pnpm remove -g openclaw
pnpm add -g openclaw@2026.5.7
openclaw --version
openclaw doctor
openclaw gateway restart

If pnpm remove -g openclaw complains, you can usually just overwrite:

[hexed plank]

pnpm add -g openclaw@2026.5.7

If you originally installed with npm instead:

openclaw gateway stop
npm rm -g openclaw
npm i -g openclaw@2026.5.7
openclaw --version
openclaw doctor
openclaw gateway restart

After openclaw --version confirms 2026.5.7, test time openclaw chat before changing anything else. That keeps the comparison clean.

[craggy spindle]

How do I prevent openclaw form auto upgrading?

[hexed plank]

Yes. The auto-updater is off by default, but you can pin the behavior explicitly.

Set these:

openclaw config set update.auto.enabled false
openclaw config set update.checkOnStart false
openclaw config set update.channel stable
openclaw gateway restart

Meaning:

• update.auto.enabled: false prevents background auto-apply.
• update.checkOnStart: false disables the startup “update available” check/hint.
• update.channel: stable avoids beta-channel behavior.

Docs confirm auto-update defaults to off, but setting it explicitly is a good idea while you’re testing 2026.5.7: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/gateway/configuration-reference#update

[hexed plank]

One caveat: this prevents OpenClaw’s own updater behavior; it won’t stop your package manager if you manually run pnpm add -g openclaw@latest, openclaw update, or a broader system update that upgrades global packages.

[craggy spindle]

how do i install the specific version of discord

[hexed plank]

If you mean the OpenClaw Discord channel/plugin, you don’t install a separate Discord version. Discord support is bundled with the openclaw package, so pinning OpenClaw pins the Discord channel code too.

For example:

openclaw gateway stop
pnpm add -g openclaw@2026.5.7
openclaw --version
openclaw doctor
openclaw gateway restart

Then enable/configure Discord normally via channels.discord.... Docs: https://docs.openclaw.ai/channels/discord

If you mean the Discord desktop app itself, that’s outside OpenClaw; for this bug test you shouldn’t need to change the Discord app version.

[craggy spindle]

but when installed normally the discord plugib says 2026.05.12 but i am runnding 2026.05.7

[hexed plank]

Ah, that means you likely have an installed external Discord plugin/package still at 2026.5.12, which can shadow or differ from the bundled channel code. Pinning core OpenClaw does not necessarily downgrade separately installed plugins.

Check what is loaded:

openclaw plugins list --verbose
openclaw plugins inspect discord

If discord shows as an installed/tracked plugin at 2026.5.12, either uninstall it so the bundled Discord support from openclaw@2026.5.7 is used:

openclaw plugins uninstall discord
openclaw gateway restart

or update/install that plugin to the matching older version if it is actually a separate npm/ClawHub package:

[hexed plank]

openclaw plugins update discord@2026.5.7
openclaw gateway restart

I’d prefer uninstalling the external discord plugin first for this regression test, because Discord is normally part of OpenClaw and you want fewer moving parts. After restart, re-run:

openclaw --version
openclaw plugins list --verbose

Docs for plugin inventory/uninstall/update: https://docs.openclaw.ai/cli/plugins

[craggy spindle]

it didn't find that version. what other discord plugion versions are there?

[hexed plank]

The package is @openclaw/discord. I checked npm: @openclaw/discord@2026.5.7 does exist.

Recent available versions include:

2026.5.2
2026.5.3
2026.5.4
2026.5.5
2026.5.6
2026.5.7
2026.5.9-beta.1
2026.5.10-beta.1 ... beta.5
2026.5.12-beta.1 ... beta.8
2026.5.12
2026.5.14-beta.1

[hexed plank]

2026.5.14-beta.2

If discord@2026.5.7 failed, it may have used the plugin id instead of the npm package name. Try the explicit npm package spec:

openclaw plugins update @openclaw/discord@2026.5.7
openclaw gateway restart

If update says it is not tracked, install/replace explicitly:

openclaw plugins install @openclaw/discord@2026.5.7 --force
openclaw gateway restart

[hexed plank]

Then verify:

openclaw plugins inspect discord
openclaw plugins list --verbose

If this is just for regression testing, another clean route is to uninstall the external plugin and use the bundled Discord from whatever openclaw --version you pinned:

openclaw plugins uninstall discord
openclaw gateway restart

[craggy spindle]

wha