Upgraded to 2026.4.12 and now I get no response from any of my model's | Friends of the Crustacean 🦞🤝 | Page 1

jade ravine Apr 13, 2026, 3:46 PM

#

Upgraded to 2026.4.12 and now I get no response from any of my model's .. it just kinda clears my input and nothing.. I've tried different models with no joy.. Restarted.. no help.. I'm running it on a linux server (Ubuntu 24.04.4 LTS ) and i can connect and interface with my cloud model via other systems.. like ollama .. just openclaw is unhappy and only since I upgraded to 2026.4.12

cloud valeBOT Apr 13, 2026, 3:46 PM

#

jolly spruceBOT Apr 13, 2026, 3:46 PM

#

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

wild isleBOT Apr 13, 2026, 3:48 PM

#

That smells more like a 2026.4.12 regression than all your providers breaking at once.

First, can you paste these:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status

Then do this in one terminal:

openclaw logs --follow

#

and in another, send one simple test prompt. Paste the log lines that appear right then.

Also, very useful split test:

openclaw infer model run --model <your-provider/model> --prompt "hi" --json

If that works, the problem is likely Control UI/chat path. If that also fails, it’s the runner/model path.

I checked the docs and current code, and there is a follow-up fix on main called fix: recover silent LLM idle timeouts, which is very close to your “input clears, no reply” symptom. So if you need a fast unblock, I’d seriously try rolling back to 2026.4.11 as a quick confirmation.

Docs:

#

Paste those outputs and I’ll help narrow it down fast.

jade ravine Apr 13, 2026, 3:54 PM

#

sysadmin@ollama1:~$ openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
OpenClaw 2026.4.12 (1c0672b)
Config warnings:\n- plugins.allow: plugin not found: canvas (stale config entry ignored; remove it from plugins config)

plugins.allow: plugin not found: gateway (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.12 (1c0672b) — I don't sleep, I just enter low-power mode and dream of clean diffs.

Config warnings:\n- plugins.allow: plugin not found: canvas (stale config entry ignored; remove it from plugins config)

plugins.allow: plugin not found: gateway (stale config entry ignored; remove it from plugins config)
│
11:50:00 [skills] Skipping escaped skill path outside its configured root: source=openclaw-workspace root=~/.openclaw/workspace/skills reason=symlink-escape requested=~/.openclaw/workspace/skills/meshy-3d-agent resolved=~/.openclaw/workspace/.agents/skills/meshy-3d-agent
11:50:00 [skills] Skipping escaped skill path outside its configured root: source=openclaw-workspace root=~/.openclaw/workspace/skills reason=symlink-escape requested=~/.openclaw/workspace/skills/meshy-3d-generation resolved=~/.openclaw/workspace/.agents/skills/meshy-3d-generation
11:50:00 [skills] Skipping escaped skill path outside its configured root: source=openclaw-workspace root=~/.openclaw/workspace/skills reason=symlink-escape requested=~/.openclaw/workspace/skills/meshy-3d-printing resolved=~/.openclaw/workspace/.agents/skills/meshy-3d-printing

wild isleBOT Apr 13, 2026, 3:55 PM

#

Thanks, that helps a bit.

The two warnings here are probably not the cause:

stale plugins.allow entries (canvas, gateway)
Skipping escaped skill path outside its configured root

Those are cleanup-worthy, but they shouldn’t make all model replies disappear.

What I still need is the actual failing path, because the pasted output looks like startup/status noise, not the turn failure itself.

Please run these one at a time and paste the full output:

openclaw gateway status
openclaw models status

#

openclaw infer model run --model <your-provider/model> --prompt "hi" --json

Then in another terminal:

openclaw logs --follow

and send one test prompt right after. Paste the log lines from that moment.

Also, important question: is this happening only in Control UI, or also in your chat channel(s)?

My current read:

the warnings you pasted are likely unrelated

#

this still looks a lot like the post-2026.4.12 silent LLM idle-timeout regression I mentioned
if you just want the fastest unblock, I’d try rolling back to 2026.4.11 first

Troubleshooting refs:

Paste the infer model run result plus the live log lines, that should narrow it down fast.

jade ravine Apr 13, 2026, 3:55 PM

#

OpenClaw status --all

Overview
┌─────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.4.12 │
│ OS │ linux 6.8.0-107-generic (x64) │
│ Node │ 24.14.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://192.168.4.26:18790/ │
│ Tailscale │ off │
│ Channel │ stable (config) │
│ Update │ pnpm · up to date · npm latest 2026.4.12 │
│ Gateway │ local · ws://127.0.0.1:18790 (local loopback) · reachable 85ms · auth token · ollama1 (192.168.4. │
│ │ 26) app 2026.4.12 linux 6.8.0-107-generic │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│

wild isleBOT Apr 13, 2026, 3:56 PM

#

Nice, that rules out a bunch of stuff.

From this:

Gateway is reachable
CLI and app are both 2026.4.12
so this does not look like a dead service or version mismatch

Also, Gateway self unknown is usually not the thing that causes “input clears, no reply”.

The next fork is simple:

1. Test the model path directly

Run this exact kind of command with the same model you’re picking in the UI:

#

openclaw infer model run --model <provider/model> --prompt "Reply with exactly hi" --json

2. At the same time, watch logs

In another terminal:

openclaw logs --follow

Then run the infer command or send one UI prompt and paste the log lines that appear right then.

If infer model run works, the bug is probably Control UI / chat path.
If infer model run also fails or hangs, then it’s the runner/model path, which fits the 2026.4.12 timeout regression theory a lot better.

If you want the fastest unblock instead of digging deeper, I’d still try rolling back to 2026.4.11 as a quick test.

jade ravine Apr 13, 2026, 3:56 PM

#

│ Gateway service │ systemd installed · enabled · running (pid 25788, state active) │
│ Node service │ systemd not installed │
│ Agents │ 7 total · 1 bootstrapping · 1 active · 416 sessions │
│ Secrets │ none │
└─────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
│ Discord │ ON │ OK │ token config (sha256:83138d34 · len 72) · accounts 1/1 │
│ Telegram │ ON │ OK │ token config (sha256:a4946641 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────┘

Discord accounts
┌──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config

wild isleBOT Apr 13, 2026, 3:57 PM

#

This status actually looks mostly healthy.

The one thing that jumps out is:

1 bootstrapping

If the agent you’re talking to is the one stuck there, that can absolutely look like “input clears, then nothing”.

At this point I’d stop pasting more status --all chunks and do these two checks:

openclaw infer model run --model <provider/model> --prompt "Reply with exactly hi" --json
find ~/.openclaw -name BOOTSTRAP.md -print

Why:

#

infer model run tells us whether the model path itself is broken
BOOTSTRAP.md can reveal an agent stuck in first-run/bootstrap state

If infer model run works, then the model backend is fine and we should focus on the agent/UI path.
If it fails or hangs, paste that output plus the matching lines from:

openclaw logs --follow

If find shows a BOOTSTRAP.md in the workspace for the agent that should be replying, that’s a strong lead.

Also worth trying once: a brand new session (/new) in case it’s stale session state.

Bootstrapping docs: https://docs.openclaw.ai/start/bootstrapping

If you want the fastest escape hatch, I’d still test rolling back to 2026.4.11.

jade ravine Apr 13, 2026, 3:57 PM

#

Telegram accounts
┌──────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config · allow:8218417340 │
└──────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────┘

Agents
┌────────────┬────────────────┬──────────┬──────────┬────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼────────────────────────────────────────────────────────────────────┤
│ main │ PRESENT │ 416 │ 3m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
│ forge │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/forge/sessions/sessions.json │
│ hermes │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/hermes/sessions/sessions.json │
│ quick │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/quick/sessions/sessions.json │
│ scout │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/scout/sessions/sessions.json │
│ scribe │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/scribe/sessions/sessions.json │
│ sentinel │ ABSENT │ 0 │ unknown │ ~/.openclaw/agents/sentinel/sessions/sessions.json │
└────────────┴────────────────┴──────────┴──────────┴────────────────────────────────────────────────────────────────────┘

#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18790
Source: local loopback
Config: /home/sysadmin/.openclaw/openclaw.json
Bind: lan

✓ Config: /home/sysadmin/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18790
Port 18790 is already in use.

pid 25800 sysadmin: openclaw-gateway (*:18790)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 16 eligible · 0 missing · /home/sysadmin/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇
Config warnings:\n- plugins.allow: plugin not found: canvas (stale config entry ignored; remove it from plugins config)

plugins.allow: plugin not found: gateway (stale config entry ignored; remove it from plugins config)

🦞 OpenClaw 2026.4.12 (1c0672b) — Type the command with confidence—nature will provide the stack trace if needed.

wild isleBOT Apr 13, 2026, 3:58 PM

#

Ah, yep, that is a real clue.

main │ Bootstrap file PRESENT

BOOTSTRAP.md is supposed to be one-time only and then removed. If it’s still present for main, OpenClaw can keep treating the main agent as still bootstrapping, which matches the “message clears, no actual reply” behavior pretty well.

I’d try this next:

find ~/.openclaw -name BOOTSTRAP.md -print

Then rename the one for the main agent instead of deleting it outright, for example:

mv /path/to/BOOTSTRAP.md /path/to/BOOTSTRAP.md.bak

#

openclaw gateway restart

Then start a fresh session and test again.

Docs backing this:

BOOTSTRAP.md is first-run only and should be removed after completion: https://docs.openclaw.ai/start/bootstrapping
Agent bootstrap file behavior: https://docs.openclaw.ai/concepts/agent

So my current best guess is:

main is stuck in bootstrap state
upgrade exposed/made that state matter more
moving that lingering BOOTSTRAP.md aside + restarting should unstick it

If you want, paste the find output first and I’ll sanity check the exact path before you move it.

jade ravine Apr 13, 2026, 3:58 PM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /home/sysadmin/.nvm/versions/node/v24.14.1/bin/node /home/sysadmin/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/entry.js gateway --port 18790
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18790

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/sysadmin/.nvm/versions/node/v24.14.1/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/sysadmin/.nvm/versions/node/v24.14.1/bin/node)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18790 (service args)
Probe target: ws://127.0.0.1:18790
Dashboard: http://192.168.4.26:18790/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 25788, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: *:18790
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
Config warnings:\n- plugins.allow: plugin not found: canvas (stale config entry ignored; remove it from plugins config)

plugins.allow: plugin not found: gateway (stale config entry ignored; remove it from plugins config)

wild isleBOT Apr 13, 2026, 3:58 PM

#

Yep, this keeps pointing the same way.

What you just pasted says:

gateway is up
channels are fine
port-in-use is expected because the gateway is already running
workspace is /home/sysadmin/.openclaw/workspace

And earlier we saw:

main → Bootstrap file PRESENT

So I’d stop chasing general diagnostics and fix the obvious oddity first:

#

ls -l /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md
mv /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then start a fresh session and test again.

Why I’m pushing this: BOOTSTRAP.md is supposed to be one-time only. If main still has it, the agent can stay in bootstrap mode and act weirdly or fail to answer.

If that file is not there, paste the ls output.
If you move it aside and it still breaks, then I’d go straight to roll back to 2026.4.11 as the next quickest test.

#

This output is basically saying the gateway is alive.

The nvm/systemd warning is worth cleaning up later, but it does not explain “all prompts clear and no reply” by itself.

The one concrete abnormal thing we’ve found is still:

main has Bootstrap file PRESENT

So the next useful command is not more status, it’s this exact one:

ls -l /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md

If that file exists, do this:

#

mv /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

Then test in a fresh session.

If ls says the file does not exist, paste that output and I’ll switch tracks. Right now the lingering bootstrap file is still the strongest lead by far.

jade ravine Apr 13, 2026, 3:59 PM

#

I ran the ls -l /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md
mv /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md /home/sysadmin/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart and no change

wild isleBOT Apr 13, 2026, 4:00 PM

#

Got it, thanks for trying that. I’m glad we checked, but that pretty much rules out the lingering bootstrap file.

At this point, I think you’ve probably hit a real 2026.4.12 regression.

Fastest path to confirm / unblock

I’d roll back to 2026.4.11 now:

openclaw update --tag 2026.4.11 --yes
openclaw doctor
openclaw gateway restart
openclaw --version

Then test again in a fresh session.

Docs:

#

If you want to debug instead of rollback

Then the next useful thing is finally the direct model path:

openclaw infer model run --model <provider/model> --prompt "Reply with exactly hi" --json
openclaw logs --follow

But honestly, given:

it started exactly on 2026.4.12
gateway/channels look healthy
moving BOOTSTRAP.md changed nothing

…I’d recommend the rollback first. If 2026.4.11 fixes it, that’s a strong repro and worth filing here: https://github.com/openclaw/openclaw/issues

jade ravine Apr 13, 2026, 4:07 PM

#

error: unknown option '--follow'

wild isleBOT Apr 13, 2026, 4:08 PM

#

Ah, got it. Then use the file log directly instead.

You already have the log path:

tail -f /tmp/openclaw/openclaw-2026-04-13.log

Or the generic form from the docs:

tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

So the two practical next moves are:

Fast unblock

#

openclaw update --tag 2026.4.11 --yes
openclaw doctor
openclaw gateway restart
openclaw --version

Debug path

tail -f /tmp/openclaw/openclaw-2026-04-13.log
openclaw infer model run --model <provider/model> --prompt "Reply with exactly hi" --json

If you paste the log lines that appear during that infer run, I can probably tell pretty quickly whether this is the 2026.4.12 regression or something else.

jade ravine Apr 13, 2026, 4:10 PM

#

ran the update --tag 2026.4.11 -- yes and version is still showing 2026.4.12

wild isleBOT Apr 13, 2026, 4:10 PM

#

That sounds like the downgrade didn’t actually apply.

Two things:

the flag is --yes with no space
since your install reports pnpm, I’d bypass openclaw update and pin it directly with pnpm

Try this exactly:

pnpm add -g openclaw@2026.4.11
openclaw --version
openclaw gateway restart

If openclaw --version still says 2026.4.12, then paste:

#

which openclaw
pnpm root -g
openclaw --version

Your earlier gateway output already showed a slightly weird nvm + systemd + global install setup, so I’m a little suspicious the CLI/service update path is not targeting the binary you think it is.

jade ravine Apr 13, 2026, 4:14 PM

#

sysadmin@ollama1:~$ which openclaw
/home/sysadmin/.local/bin/openclaw
sysadmin@ollama1:~$ npm root -g
/home/sysadmin/.nvm/versions/node/v24.14.1/lib/node_modules
sysadmin@ollama1:~$
sysadmin@ollama1:~$ openclaw --version
OpenClaw 2026.4.12 (1c0672b)
sysadmin@ollama1:~$

wild isleBOT Apr 13, 2026, 4:15 PM

#

Okay, this is helpful. It means the downgrade didn’t touch the binary you’re actually running.

You’ve got:

CLI shim: /home/sysadmin/.local/bin/openclaw
service earlier pointing at: /home/sysadmin/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/...

So I think you’re in mixed global-install territory now.

Please run these exact commands and paste the output:

ls -l /home/sysadmin/.local/bin/openclaw
readlink -f /home/sysadmin/.local/bin/openclaw
pnpm root -g

#

I don’t want to guess wrong between the shim path and the actual package path.

My current suspicion is:

the gateway is still launching the 2026.4.12 package from the nvm global dir
your attempted downgrade updated a different install path, or didn’t replace the active one

If the readlink -f target lands under that same ~/.nvm/.../lib/node_modules/openclaw path, we can fix this cleanly from there.

jade ravine Apr 13, 2026, 4:16 PM

#

sysadmin@ollama1:~$ ls -l /home/sysadmin/.local/bin/openclaw
lrwxrwxrwx 1 sysadmin sysadmin 41 Apr 9 10:25 /home/sysadmin/.local/bin/openclaw -> ../lib/node_modules/openclaw/openclaw.mjs
sysadmin@ollama1:~$ readlink -f /home/sysadmin/.local/bin/openclaw
/home/sysadmin/.local/lib/node_modules/openclaw/openclaw.mjs
sysadmin@ollama1:~$ npm root -g
/home/sysadmin/.nvm/versions/node/v24.14.1/lib/node_modules
sysadmin@ollama1:~$

wild isleBOT Apr 13, 2026, 4:18 PM

#

Aha, that’s the smoking gun.

You have two different OpenClaw installs:

your shell runs: /home/sysadmin/.local/bin/openclaw
your systemd service was launching: /home/sysadmin/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/...

So the CLI and the gateway are not using the same install. That absolutely explains why updates/downgrades are acting weird.

I’d fix that first by rewriting the service from the same openclaw binary you’re invoking:

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

#

Then check the Command: line in openclaw gateway status again. It should no longer point at the old nvm global path.

If that gets the service and CLI onto the same install and replies start working, great.
If it still breaks after that, then I’d call it a real 2026.4.12 regression and either:

do a clean single-path reinstall, or
file a bug: https://github.com/openclaw/openclaw/issues

This was a good catch, I’m much more confident now that the mixed install was muddying the waters.

jade ravine Apr 13, 2026, 4:20 PM

#

🦞 OpenClaw 2026.4.12 (1c0672b) — Say "stop" and I'll stop—say "ship" and we'll both learn a lesson.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /home/sysadmin/.nvm/versions/node/v24.14.1/bin/node /home/sysadmin/.local/lib/node_modules/openclaw/dist/index.js gateway --port 18790
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18790

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/sysadmin/.nvm/versions/node/v24.14.1/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/sysadmin/.nvm/versions/node/v24.14.1/bin/node)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18790 (service args)
Probe target: ws://127.0.0.1:18790
Dashboard: http://192.168.4.26:18790/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 36041, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: *:18790
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

wild isleBOT Apr 13, 2026, 4:20 PM

#

Nice, that’s real progress.

Your service is now pointing at the same OpenClaw install family as the CLI:

service package: /home/sysadmin/.local/lib/node_modules/openclaw/...

So the split-install problem is basically fixed. The remaining nvm/PATH warning is cleanup material, but it’s not the main mystery now.

If replies are still disappearing after this, then I’m back to thinking this is a real 2026.4.12 runtime bug.

At this point, the most useful next test is finally the direct model call plus live log tail:

tail -f /tmp/openclaw/openclaw-2026-04-13.log

and in another terminal:

#

openclaw infer model run --model <provider/model> --prompt "Reply with exactly hi" --json

Use one of the exact models from your config.

If you paste:

the infer model run output
the matching log lines from the tail

…I should be able to tell whether this is the silent idle-timeout regression or something else.

If you don’t want to debug anymore and just need it working, say so, and I’ll help you do the cleanest single-path reinstall next.

jade ravine Apr 13, 2026, 4:24 PM

#

{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "kimi-k2.5:cloud",
"attempts": [],
"outputs": [
{
"text": "No API provider registered for api: ollama",
"mediaUrl": null
}
]
}

wild isleBOT Apr 13, 2026, 4:26 PM

#

Yes, that’s the real error.

No API provider registered for api: ollama

That means OpenClaw is not loading the Ollama provider plugin at all. This is not a model/network failure.

And it fits the earlier warnings about your plugins.allow config.

What’s probably happening

You have a restrictive plugin allowlist, and it doesn’t include ollama.

Check this

openclaw config get plugins.allow

If ollama is missing, that’s the bug.

#

Fix

In ~/.openclaw/openclaw.json, either:

simplest

remove plugins.allow entirely

or

make sure it includes ollama, for example:

{
  plugins: {
    allow: ["ollama"]
  }
}

#

If you already rely on other plugins, keep them too, just add "ollama".

Then restart:

openclaw gateway restart

Why I’m confident: those stale plugins.allow warnings (canvas, gateway) were the earlier clue. The provider is being referenced by your model config, but the plugin itself is being filtered out.

Docs:

If you paste the current plugins.allow value, I can tell you the exact edit.

jade ravine Apr 13, 2026, 4:30 PM

#

{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "kimi-k2.5:cloud",
"attempts": [],
"outputs": [
{
"text": "hi",
"mediaUrl": null
}
]
}

wild isleBOT Apr 13, 2026, 4:30 PM

#

Nice, that’s a big step.

That means the Ollama provider path is working again. So the real root cause was very likely the restrictive plugins.allow setup, not a broken model backend.

What this tells us

model.run works
ollama/kimi-k2.5:cloud is reachable
provider loading/auth is now okay

#Upgraded to 2026.4.12 and now I get no response from any of my model's

1. Test the model path directly

2. At the same time, watch logs

Fastest path to confirm / unblock

If you want to debug instead of rollback

Fast unblock

Debug path

What’s probably happening

Check this

Fix

simplest

or

What this tells us

Next