openclaw not running | Friends of the Crustacean 🦞🤝 | Page 1

prisma sierra Apr 29, 2026, 11:18 PM

#

getting an error when opening up openclaw control. "internal server error." also not responding on telegram. not sure if kimi2.5 doesnt work any more with the kimi 2.6 update? cannot get openclaw doctor to run on the vps anymore either. what do you think is the issue?

buoyant snowBOT Apr 29, 2026, 11:18 PM

#

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

dense vigilBOT Apr 29, 2026, 11:19 PM

#

This smells less like Kimi and more like the gateway/CLI install or local state is broken.

If Kimi 2.5/2.6 were the only issue, Telegram would usually still receive the message and then fail during the model call. But Control UI “internal server error” + Telegram dead + doctor won’t run points earlier: gateway crash, stale install/PATH mismatch, corrupt state, or service/port problem.

First, please paste the exact output of:

openclaw --version
which openclaw
openclaw status --all
openclaw gateway status --deep
openclaw config get meta.lastTouchedVersion

Then try logs:

#

openclaw logs --follow

If that doesn’t work:

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

One specific thing to look for: if logs mention devices/pending.json, Unexpected end of JSON input, gateway closed (1000), or weird “port already in use / gateway already running” loops, that’s a known corrupted pending-device-state symptom. In that case the fix is usually:

mv ~/.openclaw/devices/pending.json ~/.openclaw/devices/pending.json.bad.$(date +%s)
openclaw gateway restart

#

But don’t do that blindly yet — paste the version + error/log output first.

Docs for the triage ladder: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting 🦐

prisma sierra Apr 29, 2026, 11:20 PM

#

tt@tt-koda:~$ openclaw --version
openclaw: command not found

cant even get an openclaw command to run now..

dense vigilBOT Apr 29, 2026, 11:21 PM

#

Yep — that means we’re below the Kimi layer now. openclaw: command not found means the CLI is missing from your shell PATH or the install got removed/broken.

On the VPS, run this first:

command -v node npm pnpm
node -v
echo "$PATH"

If pnpm exists, reinstall the CLI:

pnpm add -g openclaw@latest
pnpm approve-builds -g
hash -r

#

openclaw --version

If openclaw is still not found after that, it’s probably PNPM’s global bin not being on PATH. Try:

pnpm bin -g

Then add that directory to PATH, e.g. if it prints something like ~/.local/share/pnpm:

export PNPM_HOME="$HOME/.local/share/pnpm"
export PATH="$PNPM_HOME:$PATH"
openclaw --version

#

Once the command works again, refresh the gateway service:

openclaw gateway install --force
openclaw gateway restart
openclaw status --all

My bet: either a Node/pnpm/global install PATH change, or the gateway service is pointing at an old/missing openclaw binary. The Kimi update might be a separate issue, but fix the CLI/gateway first.

prisma sierra Apr 29, 2026, 11:23 PM

#

tt@tt-koda:~$ command -v node npm pnpm
/home/tt/.nvm/versions/node/v24.13.0/bin/node
/home/tt/.nvm/versions/node/v24.13.0/bin/npm
/home/tt/.nvm/versions/node/v24.13.0/bin/pnpm
tt@tt-koda:~$ node -v
v24.13.0

dense vigilBOT Apr 29, 2026, 11:23 PM

#

Good — Node itself is fine. So this is probably just OpenClaw CLI missing from pnpm’s global install/PATH, or the gateway service points at an old missing binary.

Run:

pnpm bin -g
pnpm list -g --depth 0 | grep openclaw

If OpenClaw isn’t listed, reinstall it:

pnpm add -g openclaw@latest
pnpm approve-builds -g
hash -r
openclaw --version

#

If pnpm add -g complains about no global bin dir, run:

pnpm setup
source ~/.bashrc
pnpm add -g openclaw@latest
hash -r
openclaw --version

Once openclaw --version works, repair the daemon:

openclaw gateway install --force
openclaw gateway restart
openclaw status --all

#

If it still fails after that, paste the output from openclaw --version and openclaw status --all. Docs: https://docs.openclaw.ai/install/node

prisma sierra Apr 29, 2026, 11:45 PM

#

"Something went wrong while processing your request. Please try again, or use /new to start a fresh session." cant get a response now on telegram or thru the openclaw control. with my kimi2.5 model. is my api key no longer in the json file for some reason?

dense vigilBOT Apr 29, 2026, 11:46 PM

#

Could be, but don’t inspect/paste the raw JSON with keys. That Telegram message is just the generic wrapper — the real cause will be in model auth/status or logs.

Run these on the VPS:

openclaw --version
openclaw models status
openclaw models status --probe --probe-provider moonshot
openclaw config get agents.defaults.model
openclaw logs --follow

If models status says Missing auth for moonshot, re-add the key:

openclaw onboard --auth-choice moonshot-api-key

#

openclaw models set moonshot/kimi-k2.6
openclaw gateway restart

Important nuance: Moonshot Kimi and Kimi Coding are separate providers. For K2.5/K2.6 you want model refs like:

moonshot/kimi-k2.5
moonshot/kimi-k2.6

with a Moonshot key. If your config says kimi/..., that’s the Kimi Coding provider and a Moonshot API key won’t match.

Docs: https://docs.openclaw.ai/providers/moonshot

prisma sierra Apr 30, 2026, 12:04 AM

#

"[assistant turn failed before producing content]"

dense vigilBOT Apr 30, 2026, 12:04 AM

#

That exact text is a sentinel, not the root error. It means: the agent/model call crashed before any assistant content streamed, and the real error is stored in logs/session metadata.

Most likely buckets now:

Moonshot/Kimi auth/model error
bad default model ref (kimi/... vs moonshot/...)
gateway/session state got wedged after earlier failures

Please run:

openclaw models status
openclaw models status --probe --probe-provider moonshot
openclaw config get agents.defaults.model
openclaw logs --limit 300 --plain

#

If the default model is Kimi K2.5/K2.6, it should look like:

moonshot/kimi-k2.5
moonshot/kimi-k2.6

not kimi/... unless you intentionally configured Kimi Coding.

Also try /new once after fixing the model/auth issue — but if the probe fails, /new won’t fix it by itself. The logs/probe output should tell us whether the key disappeared, the model name is wrong, or Moonshot is rejecting the request.

prisma sierra Apr 30, 2026, 12:09 AM

#

moonshot/kimi- │ moonshot:default (api_ │ unknown · 11.7s │
│ k2.6 │ key) │ ↳ No callable tools remain after resolving explicit tool allowlist │
│ │ │ (tools.allow: group:fs, group:runtime, group:sessions, group:memory, │
│ │ │ group:web, image); tools are disabled for this run. Fix the allowlist │
│ │ │ or enable the plugin that registers the requested tool.

dense vigilBOT Apr 30, 2026, 12:10 AM

#

That output actually says your Moonshot API key is present:

moonshot:default (api_key)

So this is probably not “key disappeared from JSON.”

The blocker shown is your tool policy:

No callable tools remain after resolving explicit tool allowlist
tools.allow: group:fs, group:runtime, group:sessions, group:memory, group:web, image

I’d remove the explicit tools.allow for now and use a profile instead. tools.allow is strict/absolute, and if it resolves to zero callable tools the run fails before the model can answer.

#

Try:

openclaw config get tools
openclaw config delete tools.allow
openclaw config set tools.profile coding
openclaw gateway restart
openclaw models status --probe --probe-provider moonshot

Then start a fresh Telegram session with /new.

If config delete isn’t available in your version, edit ~/.openclaw/openclaw.json and remove just the tools.allow array, leaving something like:

tools: {

#

  profile: "coding"
}

Docs: https://docs.openclaw.ai/gateway/config-tools

Tiny caveat: that specific output may be from the model probe, which disables tools during the probe, but the same strict allowlist can still wedge normal runs. Removing the explicit allowlist is the cleanest next step.

prisma sierra Apr 30, 2026, 12:29 AM

#

i reinstalled openclaw via onboarding and put in my API for kimi2.6 and i still cannot get any response. i havent had an issue in months i dont know why this stopped working 2 days ago

dense vigilBOT Apr 30, 2026, 12:30 AM

#

Ugh, yeah — that’s frustrating. The important clue is still the line you pasted earlier: it showed Moonshot auth exists, but the run is failing around the tool allowlist/runtime, not obviously the API key.

Also: reinstall/onboarding usually doesn’t wipe all old ~/.openclaw config/session state, so a bad tools.allow or wedged session can survive.

Try this exact split test:

openclaw infer model run --local --model moonshot/kimi-k2.6 --prompt "Reply exactly: KIMI_OK" --json

If this fails → Moonshot/API/model issue. Paste the error, but don’t paste the key.
If this works → your Kimi key/model are fine; the failure is Gateway/agent/tools/session.

Given the earlier error, I’d then do:

#

openclaw config get tools
openclaw config unset tools.allow
openclaw config set tools.profile coding
openclaw gateway restart

Then in Telegram run:

/new

and try a simple “hi”.

If it still fails, paste:

#

openclaw status --all
openclaw models status --probe --probe-provider moonshot
openclaw logs --limit 300 --plain

Redact anything secret. My current bet is: old explicit tool allowlist/config state + stricter recent behavior, not “Kimi 2.6 broke your key.”

prisma sierra Apr 30, 2026, 12:38 AM

#

i have a kimi code subscription, this is differnent from moonshot correct? what do i need to do to use this 2.6 plan? everything worked fine on kimi2.5

dense vigilBOT Apr 30, 2026, 12:38 AM

#

Yes — Kimi Code subscription and Moonshot API are different providers in OpenClaw.

Moonshot K2.6 API → moonshot/... provider, needs a Moonshot API key
Kimi Code subscription/API → kimi/... provider, needs a Kimi Code API key
The keys/model refs are not interchangeable

If your plan is Kimi Code, set it up like this:

openclaw onboard --auth-choice kimi-code-api-key
openclaw models set kimi/kimi-code
openclaw models list --provider kimi
openclaw gateway restart

Then test directly:

#

openclaw infer model run --local --model kimi/kimi-code --prompt "Reply exactly: KIMI_CODE_OK" --json

If you specifically want Moonshot-hosted K2.6, then you need the Moonshot API path instead:

openclaw onboard --auth-choice moonshot-api-key
openclaw models set moonshot/kimi-k2.6

Also, based on your earlier error, I’d still clear the strict tool allowlist:

openclaw config unset tools.allow
openclaw config set tools.profile coding

#

openclaw gateway restart

Docs: https://docs.openclaw.ai/providers/moonshot

prisma sierra Apr 30, 2026, 12:48 AM

#

tt@tt-koda:~$ openclaw infer model run --local --model kimi/kimi-code --prompt "Reply exactly: KIMI_CODE_OK" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "kimi",
"model": "kimi-code",
"attempts": [],
"outputs": [
{
"text": "KIMI_CODE_OK",
"mediaUrl": null
}
]
}

dense vigilBOT Apr 30, 2026, 12:48 AM

#

Nice — that proves the Kimi Code key + model work. So the problem is not your Kimi subscription/API key.

Now make the gateway/agent use that same model, and clear the tool-policy issue:

openclaw models set kimi/kimi-code
openclaw config unset tools.allow
openclaw config set tools.profile coding
openclaw gateway restart

Then verify through the gateway path:

openclaw infer model run --gateway --model kimi/kimi-code --prompt "Reply exactly: GATEWAY_OK" --json
openclaw models status

#

If gateway smoke passes, go to Telegram and send:

/new

then try a simple “hi”.

If gateway smoke fails, paste:

openclaw gateway status --deep
openclaw logs --limit 300 --plain

At this point we’ve narrowed it down really well: local model auth is good; remaining issue is gateway config/runtime/session/tool policy.

prisma sierra Apr 30, 2026, 12:56 AM

#

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/tt/.nvm/versions/node/v24.13.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/tt/.nvm/versions/node/v24.13.0/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

dense vigilBOT Apr 30, 2026, 12:56 AM

#

Yep — this explains the “worked for months then randomly died” part.

Your gateway service is currently tied to nvm’s Node path:

/home/tt/.nvm/versions/node/v24.13.0/bin/node

That can break after Node/npm/pnpm/OpenClaw upgrades because the always-on systemd service may point at a version-manager path that changed or no longer has the global openclaw installed. This is not a Kimi key issue — your infer --local already proved Kimi Code works.

Do the quick repair first:

nvm use 24
pnpm add -g openclaw@latest
pnpm approve-builds -g

#

hash -r

openclaw --version
openclaw doctor --repair
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

Then:

openclaw models set kimi/kimi-code
openclaw config unset tools.allow
openclaw config set tools.profile coding

#

openclaw gateway restart

Long-term, the cleaner VPS setup is to install system Node 24 or Node 22 LTS and reinstall the gateway service from that, so systemd doesn’t depend on nvm.

Docs: https://docs.openclaw.ai/install/node and https://docs.openclaw.ai/gateway/troubleshooting

prisma sierra Apr 30, 2026, 1:09 AM

#

why am i only getting one response from my claw now??

dense vigilBOT Apr 30, 2026, 1:09 AM

#

If you’re getting one response, that’s actually a useful clue: Telegram + Kimi auth are working at least once. So now we’re probably looking at session replay/state, gateway restart/crash after the first turn, or the tool allowlist still breaking normal agent runs.

Do this:

In Telegram send:

/new

Send hi
Send hi again
Immediately on VPS run:

openclaw gateway status --deep

#

openclaw channels status --probe
openclaw logs --limit 500 --plain | tail -n 200

Paste the log tail around the second failed message.

Also make sure this cleanup actually ran:

openclaw config unset tools.allow
openclaw config set tools.profile coding
openclaw models set kimi/kimi-code
openclaw gateway restart

If first message works and second fails, it’s not your Kimi Code subscription. It’s almost certainly something in the agent/session/gateway layer after the first turn.

prisma sierra Apr 30, 2026, 1:14 AM

#

2026-04-30T01:06:30.501Z warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay interval=34s eventLoopDelayP99Ms=21.5 eventLoopDelayMaxMs=13824.4 eventLoopUtilization=0.436 cpuCoreRatio=0.458 active=1 waiting=0 queued=1
2026-04-30T01:06:37.241Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 5ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=4a0851e9…b2e9 id=70ed992d…7fe4
2026-04-30T01:06:37.274Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 14ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=2b5f03ea…4ee7 id=49fb8bff…b98e
2026-04-30T01:07:34.600Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=b88b2811-5fad-491a-a456-6a5bf2525da2 sessionId=04f1d586-7919-4898-9456-0f8af6713fb8 stopReason=stop payloads=0 — surfacing error to user
2026-04-30T01:07:34.618Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"b88b2811-5fad-491a-a456-6a5bf2525da2","decision":"candidate_failed","requestedProvider":"kimi","requestedModel":"k2p5","candidateProvider":"kimi","candidateModel":"k2p5","attempt":1,"total":1,"reason":"format","code":"incomplete_result","errorPreview":"kimi/k2p5 ended with an incomplete terminal response","errorHash":"sha256:371a4b5f25db","fallbackStepType":"fallback_step","fallbackStepFromModel":"kimi/k2p5","fallbackStepFromFailureReason":"format","fallbackStepFromFailureDetail":"kimi/k2p5 ended with an incomplete terminal response","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision

#

2026-04-30T01:08:33.324Z warn diagnostic {"subsystem":"diagnostic"} liveness warning: reasons=event_loop_delay interval=33s eventLoopDelayP99Ms=21.4 eventLoopDelayMaxMs=14931.7 eventLoopUtilization=0.498 cpuCoreRatio=0.527 active=1 waiting=0 queued=1
2026-04-30T01:08:37.799Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=9039da43-e83c-40d5-aead-d3a96e920718 sessionId=04f1d586-7919-4898-9456-0f8af6713fb8 stopReason=stop payloads=0 — surfacing error to user
2026-04-30T01:08:37.813Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"9039da43-e83c-40d5-aead-d3a96e920718","decision":"candidate_failed","requestedProvider":"kimi","requestedModel":"k2p5","candidateProvider":"kimi","candidateModel":"k2p5","attempt":1,"total":1,"reason":"format","code":"incomplete_result","errorPreview":"kimi/k2p5 ended with an incomplete terminal response","errorHash":"sha256:371a4b5f25db","fallbackStepType":"fallback_step","fallbackStepFromModel":"kimi/k2p5","fallbackStepFromFailureReason":"format","fallbackStepFromFailureDetail":"kimi/k2p5 ended with an incomplete terminal response","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision

#

2026-04-30T01:09:55.889Z warn agent/embedded {"subsystem":"agent/embedded"} workspace bootstrap file MEMORY.md is 17058 chars (limit 12000); truncating in injected context (sessionKey=agent:main:telegram:direct:6933595967)
2026-04-30T01:10:54.970Z warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=36babac7-a5f6-4e84-9c48-d4c8be46300a sessionId=69ea9da5-29db-43e6-aa1c-75237864b338 stopReason=stop payloads=0 — surfacing error to user
2026-04-30T01:10:54.981Z warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"36babac7-a5f6-4e84-9c48-d4c8be46300a","decision":"candidate_failed","requestedProvider":"kimi","requestedModel":"kimi-code","candidateProvider":"kimi","candidateModel":"kimi-code","attempt":1,"total":1,"reason":"format","code":"incomplete_result","errorPreview":"kimi/kimi-code ended with an incomplete terminal response","errorHash":"sha256:4d3d781c773d","fallbackStepType":"fallback_step","fallbackStepFromModel":"kimi/kimi-code","fallbackStepFromFailureReason":"format","fallbackStepFromFailureDetail":"kimi/kimi-code ended with an incomplete terminal response","fallbackStepChainPosition":1,"fallbackStepFinalOutcome":"chain_exhausted","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":false} model fallback decision
2026-04-30T01:10:55.738Z info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=6933595967 message=4384

dense vigilBOT Apr 30, 2026, 1:14 AM

#

Found it. The log says the gateway is still using the old model:

requestedProvider: kimi
requestedModel: k2p5
error: kimi/k2p5 ended with an incomplete terminal response
fallbackConfigured: false

So your Kimi Code key works, but the actual Telegram/agent session is still on kimi/k2p5, not kimi/kimi-code.

Do this:

openclaw models set kimi/kimi-code
openclaw config set agents.defaults.models '{"kimi/kimi-code":{}}' --strict-json --merge

#

openclaw config unset tools.allow
openclaw config set tools.profile coding
openclaw gateway restart
openclaw models status --plain

Then in Telegram:

/new
/model kimi/kimi-code
hi

The sessions.resolve No session found lines are probably stale Control UI/session IDs after reinstall — hard-refresh Control UI or open a fresh dashboard URL after the gateway restart.

#

The main issue is not the API key anymore. It’s stale config/session/model selection still pointing at legacy kimi/k2p5. Docs: https://docs.openclaw.ai/providers/moonshot

#

Same smoking gun again:

requestedModel: k2p5

So Telegram is still running a session/model override on old kimi/k2p5.

Please run these exactly:

openclaw models set kimi/kimi-code
openclaw models status --plain
openclaw gateway restart

Then in Telegram, don’t reuse the old chat session state — send:

#

/new
/model kimi/kimi-code
hi

If it still logs requestedModel: k2p5 after that, check for an agent-specific override:

openclaw config get agents

Look for any model set to kimi/k2p5 under agents.list[]. Also check the allowlist:

openclaw config get agents.defaults.models

#

You want kimi/kimi-code present; old kimi/k2p5 can be removed later, but first we need the active session off it.

#

Okay, now we’ve got the real shape:

kimi/kimi-code works for raw inference ✅
Telegram sends fine ✅
Full OpenClaw agent run fails with:

kimi/kimi-code ended with an incomplete terminal response
stopReason=stop payloads=0

That means Kimi Code is returning no usable assistant content when OpenClaw sends the full agent context/tools/session payload. The MEMORY.md ... truncating warning isn’t fatal, but it confirms the full agent prompt is much heavier than the raw smoke test.

Try a “no tools / minimal context” smoke:

#

openclaw config set tools.byProvider '{"kimi":{"deny":["group:openclaw"]}}' --strict-json --merge
openclaw config set agents.defaults.bootstrapMode never
openclaw gateway restart

Then Telegram:

/new
hi

If that works, Kimi Code is choking on the full agent/tool/bootstrap payload. You can then decide whether to:

keep Kimi Code as a lighter no-tools chat model, or
use Moonshot API / Anthropic / OpenAI for full agent tool use, with Kimi as a fallback/raw model.

#

Also run this to confirm it’s not Telegram-specific:

openclaw agent --local --message "Reply exactly: AGENT_OK" --thinking off --json

If that fails too, it’s definitely the full agent runtime + Kimi Code combo, not Telegram.

Docs: https://docs.openclaw.ai/providers/moonshot and https://docs.openclaw.ai/gateway/config-agents

prisma sierra Apr 30, 2026, 1:17 AM

#

tt@tt-koda:~$ openclaw config unset tools.allow

🦞 OpenClaw 2026.4.27 (cbc2ba0) — I'm the middleware between your ambition and your attention span.

Config path not found: tools.allow

dense vigilBOT Apr 30, 2026, 1:17 AM

#

That’s okay — it means tools.allow is already not set. So stop chasing that one.

Your current log is now the real issue:

kimi/kimi-code ended with an incomplete terminal response
stopReason=stop payloads=0

So Kimi Code works for raw inference, but fails on the full OpenClaw agent payload.

Small correction from me: the config key for disabling bootstrap injection is not bootstrapMode; use this:

openclaw config set agents.defaults.contextInjection never
openclaw config set tools.byProvider '{"kimi":{"deny":["group:openclaw"]}}' --strict-json --merge

#

openclaw gateway restart

Then in Telegram:

/new
hi

If that works, Kimi Code is choking on full tools/context. You can keep it as a lighter no-tools model, or use Moonshot/Anthropic/OpenAI for full agent behavior.

To revert the diagnostic changes later:

#

openclaw config unset agents.defaults.contextInjection
openclaw config unset tools.byProvider.kimi
openclaw gateway restart

prisma sierra Apr 30, 2026, 1:26 AM

#

tt@tt-koda:~$ openclaw agent --local --message "Reply exactly: AGENT_OK" --thinking off --json
Error: Pass --to <E.164>, --session-id, or --agent to choose a session

dense vigilBOT Apr 30, 2026, 1:27 AM

#

Yep, that command just needs an explicit session id. Use a throwaway one:

openclaw agent --local \
  --session-id kimi-agent-smoke \
  --message "Reply exactly: AGENT_OK" \
  --thinking off \
  --json

If that gives the same incomplete terminal response, then we’ve confirmed it’s Kimi Code + full agent runtime, not Telegram.

Also test the reduced-context settings after setting them:

openclaw config set agents.defaults.contextInjection never

#

openclaw config set tools.byProvider '{"kimi":{"deny":["group:openclaw"]}}' --strict-json --merge
openclaw gateway restart

Then run the same agent smoke again with a fresh session id:

openclaw agent --local \
  --session-id kimi-agent-smoke-2 \
  --message "Reply exactly: AGENT_OK" \
  --thinking off \
  --json

prisma sierra Apr 30, 2026, 1:29 AM

#

tt@tt-koda:~$ openclaw agent --local
--session-id kimi-agent-smoke
--message "Reply exactly: AGENT_OK"
--thinking off
--json
01:28:05 [plugins] plugins.allow is empty; discovered non-bundled plugins may auto-load: lossless-claw (/home/tt/.openclaw/extensions/lossless-claw/index.ts). Set plugins.allow to explicit trusted ids.
01:28:09 [plugins] [lcm] Plugin loaded (enabled=true, db=/home/tt/.openclaw/lcm.db, threshold=0.75)
01:28:33 [plugins] [lcm] Plugin loaded (enabled=true, db=/home/tt/.openclaw/lcm.db, threshold=0.75)
01:29:03 [plugins] [lcm] Plugin loaded (enabled=true, db=/home/tt/.openclaw/lcm.db, threshold=0.75)

dense vigilBOT Apr 30, 2026, 1:29 AM

#

That command looks like it’s hanging during/full agent startup, and this line is suspicious:

discovered non-bundled plugins may auto-load: lossless-claw
[lcm] Plugin loaded ...

For the next test, temporarily disable that external plugin:

openclaw plugins list --enabled --verbose
openclaw plugins disable lossless-claw
openclaw gateway restart

Then rerun with a timeout so it can’t hang forever:

#

timeout 90s openclaw agent --local \
  --session-id kimi-agent-smoke-clean \
  --message "Reply exactly: AGENT_OK" \
  --thinking off \
  --json

If that works, the issue is likely the lossless-claw/LCM plugin interacting badly with Kimi/full agent runs.

If it still fails/hangs, paste the final output plus:

openclaw logs --limit 300 --plain

Tiny but important: don’t set plugins.enabled=false globally yet — that can also disable provider/runtime pieces. Just disable the non-bundled plugin for the bisect.

#openclaw not running