fresh echo
I was helped to downgrade to 5.7, 5.12 gave me too much crap, especially NOT giving feedback after tool runs...
Sent a ping again from mobile TG - got my pong. Then told OC we downgraded please check your version, tool ran and I can see the tool output in web chat with the correct version (no other output) and on the mobile it says "⚠️ Agent couldn't generate a response. Note: some tool actions may have already been executed — please verify before retrying."
What now?
twilit otterBOT
I was helped to downgrade to 5.7, 5.12 gave me too much crap, especially NOT giv...
That warning means the model run got far enough to execute at least one tool, but OpenClaw didn’t get a user-visible final assistant message back. Since it says “tool actions may have already been executed”, don’t blindly retry any command that could change state.
For this specific case, I’d do the smallest reset path first:
openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw logs --follow
Then in the same Telegram chat, send:
/reset
ping
If /reset replies and ping works, the old session was probably wedged after the version shuffle. If /reset also gives the same “couldn’t generate a response” bubble, grab the log lines from openclaw logs --follow around that turn and file it as a GitHub issue: https://github.com/openclaw/openclaw/issues
Docs for the triage ladder are here: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/help/troubleshooting
One extra thing: because you downgraded, make sure the gateway process was actually restarted after the downgrade. A stale running gateway with changed files underneath can produce very weird half-working behavior.
fresh echo
After the downgrade the gateway was restarted. I did /new and ping, got pong. Asked a question on TG session from web chat, got my current version
Then asked OC to recall last github thing was we where busy with, from TG mobile this time) it ran searches and tool calls, eventually came back with the same response on mobile, "⚠️ Agent couldn't generate a response. ..."
Here are the logs from the /new point:
05:48:22+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-05-17-0748.md
05:48:23+00:00 info channels/telegram {"subsystem":"channels/telegram"} telegram sendMessage ok chat=6...........8 message=1060
ping
05:48:55+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 240ms conn=93d8504c…2055 id=e.....2
... more ...
05:56:10+00:00 warn memory {"subsystem":"memory"} chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. Further duplicate warnings suppressed.
05:56:11+00:00 warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=394 eventLoopDelayMaxMs=12129.9 eventLoopUtilization=0.649 cpuCoreRatio=0.721 active=1 waiting=0 queued=1 phase=channels.telegram.start-account recentPhases=sidecars.restart-sentinel:0ms,sidecars.subagent-recovery:8ms,sidecars.main-session-recovery:11ms,post-attach.update-sentinel:0ms,sidecars.session-locks:57ms,post-ready.maintenance:294ms work=[active=agent:main:telegram:direct:6...........8(processing/model_call,q=1,age=1s last=model_call:started) queued=agent:main:telegram:direct:6...........8(processing/model_call,q=1,age=1s last=model_call:started)]
05:56:57+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=6.....d sessionId=8.....1 stopReason=stop payloads=0 — surfacing error to user
05:56:58+00:00 info channels/telegram {"subsystem":"channels/telegram"} telegram sendMessage ok chat=6...........8 message=1084
twilit otterBOT
After the downgrade the gateway was restarted. I did /new and ping, got pong. As...
That log narrows it down a lot: stopReason=stop payloads=0 means the agent/model run ended “normally”, but OpenClaw had zero user-visible text to send. So this is probably not Telegram delivery; Telegram successfully sent the fallback warning.
Two separate clues here:
sqlite-vec unavailable. Vector recall degraded means memory recall may be degraded after the downgrade/install change. That can make the “last GitHub thing” request weaker, but it should not by itself cause an empty final reply.event_loop_delay ... maxMs=12129 means the gateway was under noticeable event-loop pressure during the run. Worth fixing/checking, but the final failure is still the empty assistant payload.I’d isolate it like this:
openclaw --version
openclaw status --all
openclaw doctor
openclaw memory status --deep
openclaw logs --follow
Then test these exact messages from Telegram mobile after /new:
Say exactly: hello
then:
Use memory_search for "github", then answer in one short sentence even if you find nothing.
If the first works and the second fails, the break is around memory/tool-result followup. If both fail intermittently, it’s more likely model/provider/runtime instability.
Also: please include openclaw --version, model/provider, the runId, sessionId, and the log block above in a GitHub issue if it reproduces: https://github.com/openclaw/openclaw/issues
Docs refs:
twilit otterBOT
After the downgrade the gateway was restarted. I did /new and ping, got pong. As...
fresh echo
I want to make sure I follow you exactly... first after we ran doctor it said, Run "openclaw doctor --fix" to apply changes. Should I do this first before the "Hello...." tests?
twilit otterBOT
I want to make sure I follow you exactly... first after we ran doctor it said, R...
Yes, but only after you’ve looked at what Doctor wants to fix.
openclaw doctor --fix is meant for repairs/migrations, so it can change local config/state. If the Doctor output lists obvious OpenClaw repair items, run:
openclaw doctor --fix
openclaw gateway restart
openclaw doctor
Then do the Telegram tests.
If Doctor’s proposed fixes mention anything you’re unsure about, paste that specific section here first, with tokens/paths/private bits redacted. I’d rather not have you apply a mystery fix while we’re debugging an empty-response issue.
fresh echo
I had gateway.bind on "lan", changed it to "auto", not asking to --fix anymore, I did pick up some old crap when me and .29 was fighting:
Multiple state directories detected. This can split session history. │
│ - /home/other_user/.openclaw │
│ Active state dir: ~/.openclaw
"other_user" is no longer in the loop, can I remove or just ignore that?
twilit otterBOT
I had gateway.bind on "lan", changed it to "auto", not asking to --fix anymore, ...
If /home/other_user/.openclaw is genuinely an old state dir and nothing runs as other_user anymore, it’s safe to get it out of the way, but I’d archive/trash it rather than hard-delete it.
That directory can contain sessions, auth profiles, channel credentials, pairing state, logs, etc. So do this order:
openclaw gateway status
openclaw status
Confirm both point at your active state dir, ~/.openclaw, not /home/other_user/.openclaw.
Then move the old one aside/recoverably. If you have trash:
trash /home/other_user/.openclaw
If not, archive it somewhere obvious:
sudo mv /home/other_user/.openclaw /home/other_user/.openclaw.old-unused
Then rerun:
openclaw doctor
Ignoring it is also okay if nothing points there, but Doctor will keep warning because multiple state dirs really can split history when services/env vars accidentally use different homes. Since you’re debugging session weirdness, I’d remove the ambiguity.
fresh echo
Ok, did the Hello, got a greeting, did the search... and got a "No GitHub references found in memory" which I'm happy to get a reply BUT we were busy commiting to github when we started getting issues and...and...
Should I ask OC to check it's memory and other .md files? I am still running the log if you need anything there?
twilit otterBOT
Ok, did the Hello, got a greeting, did the search... and got a "No GitHub refere...
Yep, that’s useful progress: tool use + final reply is working now. The remaining issue is probably “where is the GitHub context stored?”, not the empty-response bug.
Important bit: memory_search may only be searching MEMORY.md / memory/*.md. It does not necessarily search old session transcripts unless session-memory indexing is enabled/configured. So “No GitHub references found in memory” does not prove the old chat/transcript is gone.
Ask OC this next from the same Telegram session:
Check MEMORY.md and memory/*.md for GitHub, commit, PR, issue, branch, and repo references. Then check the current session status and tell me what session key/session id you are using. If you cannot search old session transcripts, say that explicitly.
On the shell side, this is also useful:
openclaw sessions --all-agents --verbose
openclaw memory status --deep
What I’m looking for:
/newKeep the log running, but no need to paste more unless you see another incomplete turn detected, payloads=0, model error, memory error, or session/transcript repair warning.
Docs:
https://docs.openclaw.ai/reference/session-management-compaction
https://docs.openclaw.ai/reference/memory-config
fresh echo
my bad, I did not do a fresh /new again, just noticed after the memory search the following in the logs:
07:20:34+00:00 warn memory {"subsystem":"memory"} chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. Further duplicate warnings suppressed.
Can that be fixed...?
Give me a clean sequence to run and test again
twilit otterBOT
my bad, I did not do a fresh /new again, just noticed after the memory search th...
Yes, it can often be fixed, but first: that warning is not fatal. Docs say when sqlite-vec is unavailable, OpenClaw falls back to in-process cosine similarity automatically. So recall may be slower/degraded, but it should still answer.
Clean sequence:
# 1) Confirm the running install + state
openclaw --version
openclaw gateway status
openclaw status --all
# 2) Repair memory metadata/locks, then do a deep memory probe
openclaw memory status --fix
openclaw memory status --deep --verbose
# 3) Force a clean memory index pass
openclaw memory index --force --verbose
# 4) Restart after the state/config cleanup
openclaw gateway restart
# 5) Confirm the sqlite-vec warning/state after restart
openclaw memory status --deep --verbose
openclaw doctor
Then from Telegram mobile:
/new
Then:
twilit otterBOT
my bad, I did not do a fresh /new again, just noticed after the memory search th...
Say exactly: hello
Then:
Check MEMORY.md and memory/*.md for GitHub, commit, PR, issue, branch, and repo references. Then answer in one short sentence even if you find nothing.
Keep the log running. Paste only the relevant bits if either of these appears again:
chunks_vec not updated
incomplete turn detected
payloads=0
sqlite-vec
memory status
If openclaw memory status --deep --verbose says sqlite-vec is missing/module-not-found, the likely fix is reinstalling/rebuilding the OpenClaw install you downgraded to, because sqlite-vec is a bundled native dependency. Don’t disable vector search yet; let’s see the exact deep-status error first.
Docs:
https://docs.openclaw.ai/cli/memory
https://docs.openclaw.ai/reference/memory-config
fresh echo
see attached, followed the steps and got the error again: "⚠️ Something went wrong wh..."
twilit otterBOT
see attached, followed the steps and got the error again: "⚠️ Something went wro...
The attached log is the smoking claw:
provider=openrouter/openai/gpt-oss-120b
reasoning-only assistant turn detected
retrying 1/2 ... retrying 2/2
reasoning-only retries exhausted
reason=format code=incomplete_result
fallbackConfigured=false
So this is not Telegram, and it is not primarily sqlite-vec. The selected model is returning reasoning/internal content but no visible answer after tool use. OpenClaw retries with a “visible answer” continuation, then gives up because there is still nothing safe to send.
Clean next sequence:
openclaw models status
openclaw models list
Then switch off openrouter/openai/gpt-oss-120b to a model/provider you already have configured and trust for tool use:
openclaw models set <provider/model>
openclaw gateway restart
openclaw models status
From Telegram:
/new
Say exactly: hello
Check MEMORY.md and memory/*.md for GitHub, commit, PR, issue, branch, and repo references. Then answer in one short sentence even if you find nothing.
Optional but recommended so one bad model does not dead-end the run again:
openclaw models fallbacks list
openclaw models fallbacks add <provider/model>
Use a different known-good configured model for the fallback, not the same OpenRouter GPT-OSS one. For fresh “which model should I use?” advice, ask in #models; I don’t want to hand you a stale model ranking.
The sqlite-vec unavailable warning can still be cleaned up later, but the actual reply failure in this log is the model producing reasoning-only output.
twilit otterBOT
see attached, followed the steps and got the error again: "⚠️ Something went wro...
fresh echo
Chose another model, re-did the process from /new and question, it answered me "Found a GitHub reference mentioned in memory." so that already impressed me.
I see the log output: warn memory {"subsystem":"memory"} chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. Further duplicate warnings suppressed
nothing else looks funny in there
twilit otterBOT
Chose another model, re-did the process from /new and question, it answered me "...
That confirms the main breakage: the previous model was the bad piece. Switching models got tool use + memory + final answer working again.
The remaining sqlite-vec unavailable warning is lower priority. It means vector acceleration for memory search is missing, so OpenClaw falls back to slower/degraded similarity. Since recall is now returning results, I would not keep changing things in the same debugging pass.
Clean close-out:
openclaw models status
openclaw models fallbacks list
openclaw memory status --deep --verbose
openclaw doctor
If memory status --deep --verbose shows a specific sqlite-vec load error/module-not-found, save that for a separate issue or thread. The important fix here is: avoid openrouter/openai/gpt-oss-120b for this tool/memory workflow, and keep a fallback configured.
If this fixed the original “no reply after tool runs” problem, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index the useful bit for the next person.