#Bots wont execute commands after update and have been added to allowlist

1 messages · Page 1 of 1 (latest)

marble swan Mar 10, 2026, 2:51 PM

everything has been working perfect until the update and sicne the update, all bots on my tg channels (i have multiples), they all write text commands in the chat, instead of executing commands. We have added them to the allowlist, but not working, tried new sessions, restarted gatway and nothing - any ideas

frail mulchBOT Mar 10, 2026, 2:51 PM

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

vestal orbitBOT Mar 10, 2026, 2:55 PM

This usually ends up being auth/allowlist (not “Telegram is broken”), and an update can tighten the rules so stuff that used to be implicitly allowed becomes “treated as plain text”.

A couple quick checks to narrow it down:

What version did you update to?
Please paste:

openclaw --version

What kind of “commands” are showing up as text?

OpenClaw slash commands like /new, /status, /activation always?
Or shell-ish commands the bot should run via tools (and instead it just prints them)?

Telegram allowlist gotcha (super common): allowFrom is NOT bot names
From the FAQ: channels.telegram.allowFrom must be the human sender’s numeric Telegram user id, not @botname / not the bot username. If you “added the bots to the allowlist”, that’s likely the issue.
Docs: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom and https://docs.openclaw.ai/channels/telegram

Group/channels changed behavior: make sure you’re setting the group sender allowlist too
For Telegram groups, sender filtering uses groupAllowFrom (falls back to allowFrom if missing). Recent builds also have a stricter boundary where DM pairing approvals don’t automatically grant group permissions.
Docs (Group policy tab): https://docs.openclaw.ai/channels/telegram#group-policy-and-allowlists
If you set commands.allowFrom, it overrides everything
If commands.allowFrom exists and doesn’t include you, then /... commands/directives will be treated as plain text (looks exactly like “it just types commands”).
Docs: https://docs.openclaw.ai/tools/slash-commands

If you can paste:

the relevant channels.telegram block (redact token), and
whether you have a commands: { allowFrom: ... } block,
I can tell you exactly which knob is blocking it.

marble swan Mar 10, 2026, 3:11 PM

1 - Version OpenClaw 2026.3.8 (3caab92)

2- everything is showing up as text, so i ask him to read a file, send an email, any sort of action, he writes the action as text in TG, doesnt process the action

they are unable to read files, read tool files, create documents, do any sort of action

I have been using everything for about 1 month, we have extensive amounts of projects and work and this issue only happened from the update

so when it goes to read a file it type read{{"file_path": "/users.........

when we go to

openclaw config get tools

We have profile full, allow "*" , ask off

Issue summary: Tools are not being invoked. The agent outputs tool calls (like read({"file_path": "..."})) as plain text instead of executing them. Session shows capabilities=none despite tools.profile: "full" being set.

Key details:

• Channel: Webchat (openclaw-control-ui), NOT Telegram — so Telegram allowlist (points 3-4) doesn't apply
• Slash commands work fine — /new, /status, etc. all work. This is NOT a commands.allowFrom issue (point 5)
• Config verified:
{
"profile": "full",
"allow": ["*"],
"web": { "fetch": { "enabled": true } },
"exec": { "host": "gateway", "security": "full", "ask": "off" }
}
• Tried: 4+ fresh sessions (/new), full gateway restart (openclaw gateway stop/start)
• Session runtime shows: capabilities=none — tools aren't being advertised to the model

What's needed: Why does tools.profile: "full" in config not result in capabilities being advertised to the session? The model can't invoke tools it doesn't know exist.

vestal orbitBOT Mar 10, 2026, 3:16 PM

That symptom (“it literally prints read{{...}} / exec{...} into Telegram) means the model is not actually issuing a real tool call. OpenClaw can only execute tools when the provider returns a structured tool_use / tool_calls response — if the model just writes tool syntax as text, the gateway has nothing to execute, so you see it in chat.

So this is usually one of these (in order of likelihood):

1) You’re not on the model/provider you think (failover after the update)

After an update, it’s common that your primary provider auth breaks (env not loaded in the service, token expired, etc.), and OpenClaw silently fails over to a “works for chat but bad at tools” model. Those models often “roleplay” tool calls as text.

Please paste:

openclaw models status
openclaw status --all

(status --all is designed to be shareable; it redacts secrets.)

What I’m looking for:

which provider/model is actually being used
any auth errors / fallback selection

2) The gateway service is running with a different config/env than your CLI

You can have tools.profile: "full" in the CLI config, but the daemon might be using a different config file (or missing env vars), which can cascade into model/auth/failover weirdness.

Paste:

openclaw gateway status

Specifically the “Config (cli)” vs “Config (service)” lines.

FAQ reference: https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different

3) Telegram “channel” / sessionKey issue (tools show as text)

There’s a known failure mode where Telegram traffic ends up with sessionKey=unknown and tools don’t execute (they show up as text blocks). It was reported before specifically on Telegram.

Check logs for this exact string:

openclaw logs --follow

Then send one message in TG that would normally trigger a tool (e.g. “read /etc/hosts”) and look for sessionKey=unknown or tool parsing warnings. If you see sessionKey=unknown, tell me and paste ~20 lines around it.

(Related historical bug report: https://github.com/openclaw/openclaw/issues/1467)

Quick A/B test (super useful)

Does it also happen in a direct DM to the bot, or only in your TG “channels/groups”?

DM works, channel/group broken → likely group/channel tool restrictions/sandboxing or a Telegram sessionKey/routing issue.
DM also broken → almost certainly model/provider/failover or daemon env/config mismatch.

If you paste the outputs above, I can tell you which bucket you’re in and the exact fix.

A couple important clarifications first:

capabilities=none is a WebChat/UI thing, not “tools=none”.
In /status, “capabilities” is about the surface (buttons, threads, etc.). WebChat commonly reports none and that’s normal. It does not mean tools should be missing.
If the assistant is literally printing read({...}) / exec({...}) as text, then one of these is true:

The model/provider you’re on isn’t actually doing structured tool calling (so it “roleplays” tool syntax in plain text), or
Your effective tool policy is resolving to an empty tool schema for that agent/provider/session (despite what openclaw config get tools shows).

To answer “why doesn’t tools.profile: full result in tools being advertised?” — because tools.profile is just one input. The effective tool schema can still be narrowed to nothing by:

tools.deny (deny always wins)
tools.byProvider (provider/model-specific restrictions)
per-agent overrides: agents.defaults.tools.* and agents.list[].tools.*
sandbox tool policy: tools.sandbox.tools.* (and agent sandbox settings)
per-channel/per-sender overrides (less likely for WebChat, but still possible in general)
provider limitations (some providers/models just don’t support tool calls reliably)

The 2 fastest “tell me what’s actually happening” probes

A) In the broken WebChat session, run:

/context detail

and paste the part that lists tools / tool policy / sandbox (whatever it shows). That’s the quickest way to see what the gateway thinks is “effective” for that session.

B) From the terminal, paste:

openclaw models status
openclaw status --all

I want to see:

which provider/model is actually in use (and whether you’re failing over)
any auth errors that would cause fallback to a model that “fakes” tool calls as text

If you want one more targeted config check (usually reveals the culprit)

openclaw config get tools.byProvider
openclaw config get tools.deny
openclaw config get agents.defaults.tools
openclaw config get agents.list
openclaw config get tools.sandbox
openclaw config get agents.defaults.sandbox

If you paste models status + /context detail output, I can tell you precisely which precedence layer is stripping tools (or if you’ve landed on a provider that’s not tool-calling at all).

marble swan Mar 10, 2026, 4:21 PM

Question 1 — Failover/Model Check
No failover detected. System is using the correct model with active auth.
openclaw models status:
Default: kimi-coding/k2p5
Fallbacks (0) : -
Configured models (1): kimi-coding/k2p5

Auth overview:

kimi-coding: API key present (profile active)
openai: API key present (profile active)
Shell env: off
openclaw status --all (sanitized):
Version: 2026.3.8
OS: macos 15.6 (arm64)
Node: 25.5.0
Gateway: local · ws://127.0.0.1:18789 · running (pid [REDACTED])
Agents: 2 total · 2 bootstrapping · 42 sessions

Channels: Telegram ON, iMessage ON
Agents: main, claude — both PRESENT
Key finding: System is correctly on kimi-coding/k2p5 with zero fallbacks configured. Auth keys are loaded and active. No indication of provider failover or auth errors.

Question 2 — Config Mismatch Check
openclaw gateway status:
Service: LaunchAgent (loaded)
Command: [REDACTED]/node [REDACTED]/openclaw/dist/index.js gateway --port 18789
Service file: [REDACTED]/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid [REDACTED])
RPC probe: ok
Listening: 127.0.0.1:18789
Key finding: Config (cli) and Config (service) are identical — both point to ~/.openclaw/openclaw.json. No config mismatch.

Question 3 — Telegram/SessionKey Check
Update after testing: Tools still fail — output shows read({...}) as plain text instead of executing. Checked logs: sessionKey shows correctly as agent:main:main, NOT sessionKey=unknown. So this is NOT the Telegram routing issue from GitHub #1467.
Current state:
• Model/Provider: k2p5 active, no failover, auth working ✓
• Config: CLI and service configs match ✓
• Tools advertised: /context detail shows 24 tools in system prompt ✓
• SessionKey: Correct (agent:main:main), not unknown ✓
• But: k2p5 still outputs tool syntax as text instead of structured tool calls
This appears to be a kimi-coding/k2p5 provider-specific tool invocation failure in 2026.3.8. The model receives tool schemas but doesn't use them.

/context detail — Tools & Sandbox Info:
Sandbox: mode=off sandboxed=false

Tool list (system prompt text): 2,637 chars (~660 tok)
Tool schemas (JSON): 18,290 chars (~4,573 tok)

Tools: read, edit, write, exec, process, browser, canvas, nodes, cron, message, tts, gateway, agents_list, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status, web_fetch, image, pdf, memory_search, memory_get

(24 tools total)
Key finding: All 24 tools are advertised in system prompt. Sandbox is OFF. Tools ARE being sent to the model, but k2p5 is NOT invoking them.

A/B Test Result: Tools fail in BOTH Telegram DM and WebChat. Same symptom — output shows read({...}) as plain text instead of executing.
This rules out:
• Telegram sessionKey routing issues
• WebChat-specific problems
• Channel/surface differences
Confirmed facts:
• Model: k2p5 active, no failover
• Config: CLI/service match, tools.profile=full
• Tools advertised: 24 tools in system prompt ✓
• Sandbox: OFF ✓
• SessionKey: Correct (not unknown) ✓
• BUT: k2p5 outputs tool syntax as text in ALL channels
Conclusion: This is a kimi-coding/k2p5 provider tool-calling regression in 2026.3.8. The model receives tool schemas but doesn't format calls properly.

B) openclaw models status & openclaw status --all Summary:
Default: kimi-coding/k2p5
Fallbacks (0) : -
Configured models (1): kimi-coding/k2p5

Auth overview:

kimi-coding: API key present (profile active)
openai: API key present (backup, not used)
Shell env: off
No OAuth/tokens
Key: No fallbacks configured. Auth working. On correct model.
openclaw status --all key findings:
Version: 2026.3.8
OS: macos 15.6 (arm64)
Node: 25.5.0
Gateway: local · ws://127.0.0.1:18789 · running
Agents: 2 total
Channels: Telegram ON, iMessage ON
Sessions: 42 active
No auth errors detected. No model failover indicators.

Final Config Checks:
$ openclaw config get tools.deny
Config path not found: tools.deny

$ openclaw config get agents.defaults.tools
Config path not found: agents.defaults.tools

$ openclaw config get agents.list
[
{
"id": "main",
"default": true,
"name": "[REDACTED]",
"workspace": "[REDACTED]"
},
{
"id": "claude",
"name": "Claude",
"workspace": "[REDACTED]"
}
]

$ openclaw config get tools.sandbox
Config path not found: tools.sandbox

$ openclaw config get agents.defaults.sandbox
Config path not found: agents.defaults.sandbox

$ openclaw config get tools.byProvider
Config path not found: tools.byProvider
Config Checks Summary (all "Config path not found" = not set):
• tools.byProvider: NOT SET
• tools.deny: NOT SET
• agents.defaults.tools: NOT SET
• tools.sandbox: NOT SET
• agents.defaults.sandbox: NOT SET
Key Finding: NO precedence layers are narrowing tools. No deny, no byProvider, no sandbox, no per-agent overrides.

Combined Findings:
• ✅ Tools advertised in system prompt (24 tools)
• ✅ Sandbox: OFF
• ✅ No config narrowing tools
• ❌ k2p5 still outputs tool syntax as text

Conclusion for Support:
Tools are fully available and advertised — no config is blocking them. This is exclusively a kimi-coding/k2p5 provider tool-calling failure. The model receives tool schemas but doesn't format structured tool calls.
Questions:

Is k2p5 tool calling broken in 2026.3.8?
Can you verify k2p5 makes proper tool_use calls vs text output?
Is there a known issue with the kimi-coding provider API format?

vestal orbitBOT Mar 10, 2026, 4:27 PM

This is the key line in what you pasted:

Default model = kimi-coding/k2p5
Configured models (1) = only kimi-coding/k2p5
Tools are being written as text (read({...})) instead of coming back as structured tool_use.

That combination almost always means: the provider/model you’re using is not actually returning real tool calls (i.e. no tool_use stop reason), so OpenClaw has nothing to execute — it can only print what the model said.

Two important points:

1) `capabilities=none` is a WebChat surface flag, not a tool flag

WebChat often shows capabilities=none; that doesn’t control tool availability.

2) With `kimi-coding/k2p5`, tool calling is the likely incompatibility

From the OpenClaw docs, Kimi Coding is a separate provider and (crucially) it’s described as using Moonshot’s Anthropic-compatible endpoint:

https://docs.openclaw.ai/concepts/model-providers (section “Kimi Coding”)

https://docs.openclaw.ai/providers/moonshot (notes: Moonshot vs Kimi Coding are separate providers)

Your observed behavior matches the “model outputs fake tool syntax as text” failure mode we’ve seen with a few non-Anthropic/non-OpenAI endpoints: the model knows tools exist conceptually, but it doesn’t emit actual structured tool calls, so nothing runs.

What to do next (fastest path)

A/B test (5 minutes): switch the default model to a known tool-calling provider

You already have an OpenAI key present. Right now you’ve effectively allowlisted only Kimi (Configured models: 1), so you’ll need to add an OpenAI (or Anthropic) model to your config/model allowlist and set it as primary, then retry the exact same “read a file” request.

If tools immediately start executing again, you’ve confirmed:

tool pipeline is fine
WebChat is fine
kimi-coding/k2p5 isn’t producing tool_use in your setup / in 2026.3.8

If you want to stay on “Kimi”

Try the Moonshot provider (moonshot/kimi-k2.5) instead of kimi-coding/k2p5 (it’s OpenAI-compatible per docs) — but note it needs a Moonshot key (not interchangeable with Kimi Coding keys).

One more high-signal debug artifact (if you want to turn this into a clean bug report)

Grab a tiny excerpt from a session JSONL (or logs) showing the model response metadata:

provider/model
and the stopReason (stop vs tool_use)

If it’s stop on the assistant turn where it prints read({...}), that’s definitive: the tool call never happened at the provider level.

If you confirm the A/B test above, this is worth filing as a GitHub issue against kimi-coding tool calling in 2026.3.8 (with that stopReason snippet).

Yep — with that /context detail output, we can stop chasing config/tool-policy issues.

You’ve proven all the “plumbing” is correct:

sessionKey is normal (agent:main:main)
sandbox is off
24 tools + full JSON schemas are being sent to the provider
yet the model replies with plaintext pseudo tool calls (read({...})) instead of emitting structured tool calls

That means the failure is at the model/provider tool-calling capability layer, not OpenClaw’s tool allowlist.

What’s actually happening

kimi-coding/k2p5 is not producing real tool-use blocks (Anthropic-style tool_use / OpenAI-style tool_calls). It’s “roleplaying” tool usage in text.

OpenClaw can’t execute that, because there’s no structured tool invocation to dispatch.

This is the same class of failure as the “Gemini outputs fake tool call text” bug reports — except in your case it’s Kimi Coding.

Practical fix (today)

You need a model that actually tool-calls as your primary (or at least when you need tools).

Since you already have OpenAI auth present, the fastest A/B is:

Temporarily set an OpenAI (or Anthropic) model as default
Retry the same “read a file” prompt in WebChat

If tools immediately start executing, you’ve 100% confirmed kimi-coding/k2p5 tool calling is broken/incompatible in your setup on 2026.3.8.

Docs for switching defaults: https://docs.openclaw.ai/cli/models (openclaw models set <provider/model>)

“But it used to work before the update”

That’s consistent with a regression either in:

OpenClaw’s adapter for kimi-coding (Anthropic-compatible quirks), or
the Kimi Coding endpoint behavior itself

Either way, with the evidence you gathered, this is now a clean bug report.

Next step (so it actually gets fixed)

File a GitHub issue with exactly what you already posted:

version 2026.3.8
provider/model kimi-coding/k2p5
/context detail showing tool schemas are included
one session JSONL/log snippet showing the assistant turn has stopReason: stop (not tool_use) while printing read(...)

GitHub issues: https://github.com/openclaw/openclaw/issues

If you want, paste just the single assistant message JSON from the session log where it prints read(...) (redact ids/tokens) and I’ll tell you what to highlight (stopReason fields etc.).

That’s a known regression with Kimi Coding tool calls, and you’ve basically reproduced it perfectly.

In CHANGELOG.md on main there’s an Unreleased fix that matches your symptom word-for-word:

“Models/Kimi Coding: send anthropic-messages tools in native Anthropic format again so kimi-coding stops degrading tool calls into XML/plain-text pseudo invocations instead of real tool_use blocks.”
Source: https://raw.githubusercontent.com/openclaw/openclaw/main/CHANGELOG.md (Unreleased → Fixes)

So: nothing is wrong with your tools/profile/sessionKey/sandbox — kimi-coding/k2p5 in 2026.3.8 is sending/receiving tools in a way that causes the model to “fake” them as text.

What to do (fastest)

Upgrade to a build that includes that fix (i.e. newer than 2026.3.8). Since it’s currently in Unreleased, the quickest way is to go to dev:

openclaw update --channel dev
# (it will restart the gateway unless you pass --no-restart)

Docs for this command: https://docs.openclaw.ai/cli/update

Afterwards confirm:

openclaw --version

You should see 2026.3.9 (or at least a newer commit than 3caab92).

Then retry a simple tool prompt (“read a file”, “exec date”). You should start seeing real tool execution again (no more read({...}) text).

If you don’t want `dev`

Workaround until 2026.3.9 ships: switch your default model away from kimi-coding/k2p5 to a provider that tool-calls reliably, then switch back once 2026.3.9 is released.

If updating to dev doesn’t fix it, paste the first ~30 lines around that fix’s commit hash from openclaw --version and we’ll verify you’re actually past the patched point.

Yes — kimi-coding/k2p5 tool calling is broken in 2026.3.8 (in the exact way you’re seeing).
“Tools are advertised, sandbox is off, sessionKey is fine, but the model outputs read({...}) as plain text” matches a known Kimi Coding regression where tool payloads are not being sent in the format the Kimi Coding endpoint actually responds to with real tool_use.
Verification / “does k2p5 ever produce real tool_use?” — yes, but only once the compatibility fix is present.
This is explicitly called out as fixed on main in the changelog (currently under Unreleased):

“Models/Kimi Coding: send anthropic-messages tools in native Anthropic format again so kimi-coding stops degrading tool calls into XML/plain-text pseudo invocations instead of real tool_use blocks.” (PRs #38669, #39907, #40552)

So the expected observable difference after the fix is:

session log stopReason becomes tool_use (or equivalent), and
you’ll see actual tool execution events/results instead of text “tool syntax”.

Known issue with the kimi-coding provider API format?
Yes. Kimi Coding is Anthropic-compatible, but it’s not 1:1 with Anthropic in how tool definitions / tool_choice need to be expressed, and OpenClaw has had to carry compatibility logic for it (and it has regressed before). Your report is exactly that compatibility layer regressing in 2026.3.8.

What to do

Since the fix is in Unreleased (i.e. not in v2026.3.8), you have two real options:

Option A (recommended): update to `dev` (main) to pick up the fix

openclaw update --channel dev

Docs: https://docs.openclaw.ai/cli/update

Then confirm you’re past 2026.3.8:

openclaw --version

Option B: temporarily switch off `kimi-coding/k2p5`

Use any model/provider that reliably emits structured tool calls until 2026.3.9 (or whatever release includes that Unreleased fix) ships.

If you do Option A and it still prints plaintext tool calls, paste:

openclaw --version (full line)
one assistant-turn JSONL entry showing stopReason + provider/model
and we can confirm whether you’re actually on a build that includes the Kimi tool-format fix.

marble swan Mar 10, 2026, 4:58 PM

is it possible to roll back to a previous version, as everything was working perfectly, we have been doing alot the last 4+ weeks and today everything has went bad since the update, so if i can rollback thats maybe the best option

vestal orbitBOT Mar 10, 2026, 4:59 PM

Yes — rollback/pinning is supported, and given you were “working perfectly” pre‑2026.3.8 it’s a totally reasonable stopgap.

Docs section: Updating → Rollback / pinning
https://docs.openclaw.ai/install/updating#rollback--pinning-when-something-breaks

Safest rollback flow (macOS)

0) Take a snapshot first (strongly recommended)

Since you’ve been doing real work for weeks, grab a backup before changing versions:

openclaw backup create

(At minimum, copy ~/.openclaw/openclaw.json, ~/.openclaw/credentials/, and your workspace ~/.openclaw/workspace somewhere safe.)

1) Pin to the last known-good version (likely 2026.3.7)

If you installed globally (most mac installs do), use the same package manager you originally used:

npm:

npm i -g openclaw@2026.3.7

pnpm:

pnpm add -g openclaw@2026.3.7

Then confirm:

openclaw --version

2) Repair/migrate state + restart

openclaw doctor
openclaw gateway restart

3) Re-test a tool call (read/exec) in WebChat or Telegram DM

Note

Downgrading by one patch/minor version is usually fine, but if 2026.3.8 wrote new state/config fields, openclaw doctor is what keeps you out of trouble.
Longer-term, the proper fix for your Kimi Coding tool-calling regression is to update forward once the fix ships (it’s already in main per changelog), but rollback is the fastest way to get unblocked today.

If you tell me what version you were on right before the update (or paste your shell history line), I can tell you the exact version to pin to.

marble swan Mar 10, 2026, 5:50 PM

ok so i rolled back and didnt fix it, I have claude code and also an open ai key

I dont want to switch my primary just yet from kimi2.5 as we have alot of knowledge, history here

Can you tell me how i spawn a Claude Code instance, either in TG or in the web chat - so i can test it with that, or even with the open Ai api key, while leaving the default in tact

vestal orbitBOT Mar 10, 2026, 5:54 PM

Yes — you can test Claude Code (or Codex) via an ACP session without changing your default Kimi model. This is exactly what ACP is for: it runs an external coding harness in parallel, while your normal chats keep using kimi-coding/k2p5.

Docs (worth skimming): https://docs.openclaw.ai/tools/acp-agents

Quickest way (works from Telegram DM or WebChat)

1) Check ACP is available

In the chat, run:

/acp doctor

If ACP isn’t enabled/installed yet, also try:

/acp install

That command prints the exact enable/install steps for your host.

2) Spawn a one-shot Claude Code run (does not bind a thread)

Send (in TG DM or WebChat):

/acp spawn claude --mode oneshot --thread off --cwd ~/.openclaw/workspace

Then give it a concrete test task right after, e.g.:

“List the files in the cwd and read AGENTS.md, then summarize it.”
“Read <some path> and tell me the first 20 lines.”

This keeps your default model intact; it just runs a separate ACP turn and reports back.

If you want it persistent (so follow-ups go to the same Claude Code session)

Persistent thread-binding only works on thread-capable surfaces (Discord threads; Telegram topics). For Telegram DMs + WebChat there’s usually no thread to bind, so you’ll typically use oneshot runs, or you can steer a specific session explicitly.

You can list sessions and steer them with:

/acp sessions
/acp steer <message>
/acp status
/acp close

Testing OpenAI without changing the default

Same idea: spawn an ACP session with codex if you have Codex auth set up (Codex is usually OAuth, not just an API key). If you only have an OpenAI API key, the simplest “no-default-change” test is a session-only model override (e.g. /new <model> or /model <model>), but since your configured model allowlist currently only includes Kimi, you may need to add one OpenAI model to the allowlist first.

If you run /acp doctor and paste what it says (enabled vs not, missing backend, etc.), I can tell you the exact next command for your setup.

marble swan Mar 10, 2026, 6:39 PM

We rolled back, but when we rolled back it didnt work, actually went worse, then we upgraded back, then went to the dev upgraded and now its working as far as i can see- test files, emails, all commands seem to be executing.

When it comes to a future release and as i am on a Dev release, is there something I will need to do or will openclaw update work

Also is kimi2.5 not a good model to use for openclaw and should we switch? We have Kimi, Claude and Open Ai, but prefer Kimi as an all rounder and then depending on the scope of the project push to Api's, but if long term Kimi is going to be a problem we are best to switch

thanks for your help.

vestal orbitBOT Mar 10, 2026, 6:40 PM

Good — that lines up exactly with what we saw in the changelog: the Kimi Coding tool-format fix is on main, so dev was the quickest way to get it.

1) When the next stable release ships, do you need to do anything special?

Nope. You have two clean options:

Stay on dev and just keep pulling main:
```
openclaw update
openclaw update status
```

Switch back to stable/beta once the fixed release is published:

openclaw update --channel stable
# or
openclaw update --channel beta

openclaw update is designed to handle channel switching (it’ll align the install method too: dev→git checkout, stable/beta→npm). Docs: https://docs.openclaw.ai/cli/update

Pragmatically: I’d stay on dev until you see the next stable that includes the Kimi tool-calling fix, then flip back to stable with the command above.

2) Is Kimi 2.5 a “bad” default for OpenClaw?

Not inherently. It can be a solid all‑rounder. The tradeoff is: non-Anthropic/non-OpenAI providers tend to have more edge-case compatibility regressions around tools, because “tool calling” isn’t truly standardized across all “compatible” endpoints.

How to make Kimi safe long-term without giving it up:

Don’t run single-provider-only. Keep Claude and/or OpenAI configured and allowed so you can switch quickly when something weird happens.
Use Kimi as your primary, but keep a tool-reliable fallback ready for “must execute tools correctly” workflows.
If a workflow is critical (file ops, email sending, automation), it’s worth doing it on the model you trust most for tool calling consistency, even if Kimi is your default chat brain.

If you want, paste your current agents.defaults.model block (redacting secrets) and I’ll suggest a minimal “Kimi primary + Claude/OpenAI backup” setup that preserves your history and keeps the escape hatch easy.

And if this thread’s resolved now: please mark the solution message (right-click → Apps → ✅ Mark Solution) so Answer Overflow indexes it.