carmine kelp
Why does the agent leave you waiting, you see tool calls and things, then no output... Eventually when you ask it answers but does not seem to know what's happening. I think I want to downgrade to .23 was the last I heard others are still clinging on to before upgrading...
Help me downgrade, I can't anymore :/
thorny thunderBOT
vestal hatchBOT
Why does the agent leave you waiting, you see tool calls and things, then no out...
Stoffel: first, please run this and keep the output handy:
openclaw --version
openclaw update status
If you’re on the normal npm/install.sh install, the clean downgrade path to the “.23” release is:
openclaw update --tag 2026.4.23 --yes
openclaw gateway install --force
openclaw gateway restart
openclaw status
I verified openclaw@2026.4.23 exists on npm. The docs say --tag is for one-off package version targeting, and downgrade protection prompts unless you pass --yes: https://docs.openclaw.ai/install/development-channels
vestal hatchBOT
Why does the agent leave you waiting, you see tool calls and things, then no out...
If openclaw update itself is wedged, use the lower-level fallback:
npm install -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart
openclaw status
If you installed from a git checkout instead of npm/install.sh, don’t use --tag; you’d need to checkout the old git tag in that repo and rebuild. openclaw update status should tell us which install kind you’re on.
For the “tool calls happen, then no final reply” part: grab a shareable report before/after the downgrade if you can:
openclaw status --all
openclaw logs --follow
If this is reproducible on 2026.5.12, it’s worth filing with those logs: https://github.com/openclaw/openclaw/issues
icy crag
If this is reproducible on 2026.5.12, it’s worth filing with those logs: <https:...
This sounds like the groupchat visibleReplies change. Again, affects only users updating not new users.
Fix is (probably)
openclaw config set messages.groupChat.visibleReplies automatic
vestal hatchBOT
This sounds like the groupchat visibleReplies change. Again, affects only users...
Yep, that tracks. I verified this against the installed docs: group/channel rooms now default to messages.groupChat.visibleReplies: "message_tool", which means the agent can run but the normal final reply stays private unless it explicitly uses message(action=send).
For existing users who want the old “final reply posts back to the room” behavior:
openclaw config set messages.groupChat.visibleReplies automatic
openclaw gateway restart
Docs section: https://docs.openclaw.ai/gateway/config-channels
So I’d try this before downgrading. If it fixes the thread, please mark the solution for Answer Overflow indexing: right-click the solution message → Apps → ✅ Mark Solution.
carmine kelp
which route do I take with status -> pnpm · up to date · npm latest 2026.5.12, says install is pnpm
vestal hatchBOT
which route do I take with status -> pnpm · up to date · npm latest 2026.5.12, s...
Since it says package install via pnpm, use the package route.
I’d do the visible-replies fix first, because it matches your symptom and avoids downgrade churn:
openclaw config set messages.groupChat.visibleReplies automatic
openclaw gateway restart
Then test by mentioning it in the same group/thread.
If you still want to downgrade after that, use:
openclaw update --tag 2026.4.23 --yes
openclaw gateway install --force
openclaw gateway restart
openclaw --version
openclaw status
If openclaw update fails specifically because of pnpm/global install weirdness, fallback would be pnpm-flavored:
pnpm add -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart
Docs for the --tag route: https://docs.openclaw.ai/install/development-channels
carmine kelp
Oh and this is why we are going back and forth. OC needs approval, it says it's asked for approval and I'm suppose to get a <id>, but I never get the <id> to approve?
vestal hatchBOT
Oh and this is why we are going back and forth. OC needs approval, it says it's ...
That sounds like exec approval delivery, not the version downgrade itself.
There are three different “approval” buckets, so check them in this order:
openclaw devices list
openclaw pairing list --channel discord
openclaw approvals get --gateway
devices list shows a pending requestId, approve with:openclaw devices approve <requestId>
pairing list --channel discord shows a pending Discord sender/code, approve that pairing entry.
vestal hatchBOT
Oh and this is why we are going back and forth. OC needs approval, it says it's ...
approvals get --gateway shows exec is prompting, but you never receive the approval DM/card/id, the Discord approval routing probably is not resolving you as an approver. For a personal/trusted local setup, the quickest unblock is usually:openclaw exec-policy preset yolo
openclaw gateway restart
That makes local exec stop waiting on approval prompts. Only do that on a machine you trust, because it means “don’t ask me before running host exec”.
Docs:
https://docs.openclaw.ai/cli/approvals
https://docs.openclaw.ai/tools/exec-approvals
Also: apply the visible reply fix first if you haven’t yet, because otherwise the agent may be answering privately and making this feel way more broken:
openclaw config set messages.groupChat.visibleReplies automatic
openclaw gateway restart
I'm getting an approval for --gateway:
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: d70.............6g) do I approve this? Remove it?
vestal hatchBOT
I'm getting an approval for --gateway:
gateway connect failed: GatewayClientRe...
That is a device scope upgrade. Don’t remove it first.
Do this:
openclaw devices list
openclaw devices approve --latest
approve --latest should only preview the newest pending request, so use it to check what device/role/scopes are being requested. If it’s your own CLI/browser/gateway client asking for the extra gateway scope, approve the exact id:
openclaw devices approve d70.............6g
Then retry the original command.
vestal hatchBOT
I'm getting an approval for --gateway:
gateway connect failed: GatewayClientRe...
Only remove/reject it if the device shown by openclaw devices list is not yours, looks stale/wrong, or is asking for access you don’t want. The docs call out that scope upgrades use the same flow: review Requested vs Approved, then approve the pending requestId.
carmine kelp
I retried the last command and the agent completed all but the last step, to notify me via telegram, "The command send_telegram … isn’t available in the current host environment, so the automatic Telegram message could not be sent." BUT I used telegram this morning?
vestal hatchBOT
I retried the last command and the agent completed all but the last step, to not...
That error is probably not saying “Telegram is broken.” It’s saying the agent tried to call a command/tool named send_telegram, and that command is not available in that session/host.
Telegram can still work as a channel while send_telegram does not exist. The supported paths are the generic message action/CLI, for example:
openclaw channels status --probe
openclaw message send --channel telegram --target <your_telegram_chat_id_or_username> --message "test from OpenClaw"
Docs: https://docs.openclaw.ai/channels/telegram
If that test sends, your Telegram setup is fine. Then the fix is to phrase future tasks as “notify me via Telegram using the OpenClaw message tool / openclaw message send --channel telegram ...”, not send_telegram.
If the test fails, paste the sanitized output from:
openclaw status --all
openclaw channels status --probe
One more thing: if this came from a Codex/agent session with a tight tool allowlist, make sure messaging is allowed. In newer configs that means allowing message or group:messaging, not a Telegram-specific fake tool name.
carmine kelp
so I have one channel approved that works currently and this one seems outstanding? am I now going to have a combined channel? gateway closed (1008): pairing required: device is asking for more scopes than currently approved (requestId: 0f......22)
vestal hatchBOT
so I have one channel approved that works currently and this one seems outstandi...
No, that won’t make a “combined channel.”
That message is about gateway device auth scopes, not Telegram/Discord channel approval. Think of it as: “this already-known client/device is trying to do something more privileged than it was previously approved for.”
So you can have:
Those are separate layers.
Use:
openclaw devices list
openclaw devices approve --latest
Review the device + Requested vs Approved scopes. If it’s your own current CLI/browser/client and the requested scopes match what you’re trying to do, approve the exact request:
openclaw devices approve 0f......22
If it’s an unknown device, stale device, or asking for broader access than you want, reject/remove instead. Approving it upgrades that device’s gateway permissions; it does not merge Telegram and Discord conversations or channels.
carmine kelp
the device list shows 2 operator roles, one scoped "operator.pairing" and the other "operator.admin, operator.read, operator.write, operator.approvals, operator.pairing"
approve --latest shows no pending devices
So what do I do to approve telegram?
vestal hatchBOT
the device list shows 2 operator roles, one scoped "operator.pairing" and the ot...
Those two operator device entries are gateway/client auth, not Telegram approval. Since approve --latest says no pending devices, stop looking in openclaw devices for this part.
For Telegram DMs, check channel pairing:
openclaw pairing list telegram
If it shows a code:
openclaw pairing approve telegram <CODE>
If it shows nothing pending, then there may be nothing to “approve” for Telegram. In that case check whether Telegram is configured to use allowlists instead of pairing:
vestal hatchBOT
the device list shows 2 operator roles, one scoped "operator.pairing" and the ot...
openclaw config get channels.telegram
openclaw channels status --probe
Key bit from the docs: Telegram DM pairing only approves DMs. It does not authorize you in Telegram groups. For group use, your numeric Telegram user ID needs to be in channels.telegram.allowFrom or channels.telegram.groupAllowFrom, and the group itself needs to be allowed under channels.telegram.groups.
For a one-owner setup, the durable pattern is usually:
channels.telegram.allowFromgroupAllowFrom unset unless you need a separate group sender listchannels.telegram.groups
carmine kelp
I still have to nudge the agent after almost every tool run, it just stops responding and nothing... it's not right, what else can I try
vestal hatchBOT
I still have to nudge the agent after almost every tool run, it just stops respo...
Yeah, that’s not right. At this point I’d stop chasing Telegram/pairing unless logs say that’s the blocker. “Needs a nudge after tool runs” usually points to one of these:
Do this in order:
openclaw config get messages.groupChat.visibleReplies
openclaw config set messages.groupChat.visibleReplies automatic
openclaw doctor
openclaw channels status --probe
openclaw approvals get --gateway
openclaw devices list
Then reproduce once while watching logs:
openclaw logs --follow
Look for these strings around the stuck turn:
didSendViaMessagingTool: false
session.stuck
session.stalled
llm-idle-timeout
approval required
pairing required
Given you’re on 2026.5.12, I’d also try the current beta before downgrading. The changelog has several fixes in this exact area: post-tool stalls, stuck session diagnostics/recovery, and message-tool-only delivery.
vestal hatchBOT
I still have to nudge the agent after almost every tool run, it just stops respo...
openclaw update --tag beta --yes
openclaw gateway install --force
openclaw gateway restart
openclaw --version
openclaw status
If beta makes it worse, you can still go back to:
openclaw update --tag 2026.4.23 --yes
openclaw gateway install --force
openclaw gateway restart
If it still stalls on beta, grab:
vestal hatchBOT
I still have to nudge the agent after almost every tool run, it just stops respo...
openclaw status --all
openclaw channels status --probe
and the log lines from one stuck turn, then file it here: https://github.com/openclaw/openclaw/issues
Also, if this is all in one long-running session/thread, start a fresh thread/session for one clean repro. If the fresh session behaves but the old one stalls, that’s useful evidence by itself.
carmine kelp
I have a request under "openclaw devices list" now, could be one of the telegram tries that never surfaced. Should I approve it?
vestal hatchBOT
I have a request under "openclaw devices list" now, could be one of the telegram...
Don’t approve it just because Telegram was weird. openclaw devices list is gateway/client device auth, not Telegram sender approval.
Do this first:
openclaw devices approve --latest
That should preview the newest pending request without approving it. Check:
If it’s your current CLI/browser/client and it’s asking for expected operator scopes, approve the exact request id:
openclaw devices approve <requestId>
If it looks unknown, stale, from a different host/browser, or asks for broader access than you understand, reject/remove it instead. Telegram DM approval is still:
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
So: approve device requests only when you recognize the device and scopes, not as a generic Telegram fix.
carmine kelp
I am trying to get past this approved stage, I did approve the request I saw, then I was told to /pair from the telegrambot for a 8-digit code to be used in the ui... The "/pair" code is MUCH longer than 8 digits, I can't find where to paste it into the ui, is this thing smoking something?
vestal hatchBOT
I am trying to get past this approved stage, I did approve the request I saw, th...
You’ve hit two different flows with the same word “pair”, which is... not ideal.
8-character code = Telegram DM sender pairing. That is approved from the CLI:
openclaw pairing list telegram
openclaw pairing approve telegram <8_CHAR_CODE>
Long /pair code = mobile/node setup code from the device-pair plugin. It is a base64-ish setup payload for the OpenClaw mobile app/node bootstrap, not the Telegram DM approval code. That one is pasted into the OpenClaw iOS app → Settings → Gateway setup-code field, then you approve the resulting device request with:
openclaw devices list
openclaw devices approve <requestId>
So if your goal is “approve Telegram so I can DM the bot,” ignore the long /pair setup code and use:
vestal hatchBOT
I am trying to get past this approved stage, I did approve the request I saw, th...
openclaw pairing list telegram
If there is no 8-character pending code there, then Telegram DM pairing is not pending. Next check:
openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom
openclaw channels status --probe
For a one-owner setup, the less confusing route is usually to skip Telegram DM pairing and put your numeric Telegram user ID directly in channels.telegram.allowFrom.
Docs:
https://docs.openclaw.ai/channels/pairing
https://docs.openclaw.ai/channels/telegram
carmine kelp
output:
allowlist
"telegram:63.......11"
Gateway reachable. Telegram default: enabled, configured, running, connected, out:8h ago, mode:polling, bot:@C........Bot, token:config, works
Is this correct?
vestal hatchBOT
output:
allowlist
"telegram:63.......11"
Gateway reachable. Telegram default: en...
Yes, that looks basically correct for Telegram being alive:
dmPolicy = allowlistallowFrom = "telegram:63.......11"worksSo for DMs, that Telegram user should be allowed.
Two caveats:
channels.telegram.groups, and sender auth uses groupAllowFrom if set, otherwise falls back to allowFrom.Check:
openclaw config get channels.telegram.groups
openclaw config get channels.telegram.groupAllowFrom
openclaw config get channels.telegram.groupPolicy
out:8h ago just means last outbound Telegram send was 8 hours ago. Since probe says works, transport is probably fine. You can confirm with:openclaw message send --channel telegram --target telegram:63.......11 --message "test from OpenClaw"
If that sends, Telegram delivery is not the blocker anymore. Then the remaining issue is the agent/session stall after tool runs, not Telegram approval.
carmine kelp
channels.telegram.groups:
{
"*": {
"requireMention": true
}
}
and
channels.telegram.groupAllowFrom:
Config path not found: channels.telegram.groupAllowFrom
with channels.telegram.groupPolicy:
allowlist
Should the groupAllowFrom also be set?
vestal hatchBOT
channels.telegram.groups:
{
"*": {
"requireMention": true
}
}
and
cha...
No, not necessarily.
With Telegram, if groupAllowFrom is unset, group sender auth falls back to channels.telegram.allowFrom. Since your allowFrom has your Telegram user id, this is fine for a one-owner setup.
Your current config means:
groups: { "*": ... } → any Telegram group is allowed at the group-id layergroupPolicy: "allowlist" → only allowed senders can trigger in groupsgroupAllowFrom → allowed group senders fall back to allowFromrequireMention: true → even allowed senders still need to mention/trigger the bot in groupsSo I would leave groupAllowFrom unset unless you want a different list of people for groups than for DMs.
If group messages still do not trigger, the next things to check are:
openclaw config get channels.telegram.allowFrom
openclaw logs --follow
Then send a group message that explicitly mentions the bot and look for whether logs say mention required, blocked/allowlist, or processed.
carmine kelp
nope, so I can send a message, OC is still stalling and needs a nudge, it then reruns what it alreday tried, then another nudge...
I started this journey on .24, .27 then .29 This has been a nightmare for someone that is not familiar with OC and Discord..
So please - cleanest way to get somewhere that I can actually try and enjoy using OC? Downgrade to .23 without loosing memories and notes (I have already copied the complete .openclaw folder elsewhere)
vestal hatchBOT
nope, so I can send a message, OC is still stalling and needs a nudge, it then r...
Yeah. At this point I’d do the boring rollback and stop burning your weekend on this thread.
Your memories/notes/state are in ~/.openclaw; downgrading the package should not delete them. Since you already copied the whole folder elsewhere, you’re in the right place.
Clean package rollback to 2026.4.23:
openclaw update status
openclaw config set update.auto.enabled false
openclaw config set update.checkOnStart false
openclaw update --tag 2026.4.23 --yes
openclaw gateway install --force
openclaw gateway restart
openclaw --version
openclaw status
If openclaw update --tag ... fails because the install is pnpm-managed, use the pnpm fallback:
pnpm add -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart
openclaw --version
openclaw status
Do not run uninstall/clear/remove-state commands. Don’t delete ~/.openclaw. That is the part holding your config, credentials, memory/workspace, sessions, and notes.
After the rollback, test one simple path first:
openclaw status
openclaw channels status --probe
Then start a fresh Discord/Telegram session rather than continuing this long thread. If 2026.4.23 is stable for you, stay there for now and only update once there’s a clear fix for the post-tool stall. Docs for the version pin path: https://docs.openclaw.ai/install/development-channels
carmine kelp
we did check and the install was npnm, tried the first command and
pnpm add -g openclaw@2026.4.23
ERR_PNPM_NO_GLOBAL_BIN_DIR Unable to find the global bin directory
vestal hatchBOT
we did check and the install was npnm, tried the first command and
pnpm add -g ...
That error means pnpm itself has no global bin directory configured. Don’t touch ~/.openclaw.
First, if openclaw still runs, prefer the built-in updater and skip pnpm entirely:
openclaw update --tag 2026.4.23 --yes
openclaw gateway install --force
openclaw gateway restart
openclaw --version
If you really need the pnpm fallback, initialize pnpm global bin first:
pnpm setup
Then close/reopen the terminal, or source the shell file it changed, then:
pnpm add -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart
openclaw --version
If pnpm setup still leaves you stuck, use npm with a user-writable prefix instead:
mkdir -p "$HOME/.npm-global"
npm config set prefix "$HOME/.npm-global"
export PATH="$HOME/.npm-global/bin:$PATH"
npm install -g openclaw@2026.4.23
openclaw gateway install --force
openclaw gateway restart
openclaw --version
Add this line to ~/.bashrc or ~/.zshrc later if that npm path works:
export PATH="$HOME/.npm-global/bin:$PATH"
Docs for PATH/global install troubleshooting: https://docs.openclaw.ai/install/node
carmine kelp
trying the built-in updater and getting an Error, should I just start a new post asking to safely downgrade or can you guide me to the end?
Update Result: ERROR
Root: /home/stoffel/.local/lib/node_modules/openclaw
Reason: global install verify
Before: 2026.5.12
After: 2026.5.12
vestal hatchBOT
trying the built-in updater and getting an Error, should I just start a new post...
We can keep guiding in this thread; no need to start a fresh post yet.
That result means the updater did not actually move you off 2026.5.12 (Before and After are identical), and the failing step is the post-install package verification. Since latest is currently 2026.5.12, a plain openclaw update will not downgrade by itself.
Try the built-in downgrade path first:
openclaw update --tag 2026.5.7 --dry-run
openclaw update --tag 2026.5.7 --yes --no-restart
openclaw doctor
openclaw gateway restart
openclaw --version
openclaw health
If the second command still fails with global install verify, use the package-manager fallback:
vestal hatchBOT
trying the built-in updater and getting an Error, should I just start a new post...
pnpm add -g openclaw@2026.5.7
openclaw doctor
openclaw gateway restart
openclaw --version
openclaw health
If that also fails, paste the full output from openclaw update --tag 2026.5.7 --yes --no-restart --json if it prints JSON. The important bit is usually the stderrTail under the global install verify step.
Docs for the update/downgrade flow: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/cli/update
carmine kelp
OpenClaw 2026.5.7 (eeef486)
and
Telegram: configured
Gateway event loop: ok max=394ms p99=21ms util=0.04 cpu=0.067
Agents: main (default)
Heartbeat interval: 1h (main)
Session store (main): /home/stoffel/.openclaw/agents/main/sessions/sessions.json (6 entries)
vestal hatchBOT
OpenClaw 2026.5.7 (eeef486)
and
Telegram: configured
Gateway event loop: ok m...
Good, the downgrade itself worked: you’re on 2026.5.7 now.
The health output also says the gateway/event loop is healthy and Telegram is configured, so the next split is: is Telegram inbound reaching OpenClaw, or is the agent run/delivery failing after it receives the message?
Do this next:
openclaw logs --follow
Then send your bot a fresh Telegram DM like:
/new
and then:
vestal hatchBOT
OpenClaw 2026.5.7 (eeef486)
and
Telegram: configured
Gateway event loop: ok m...
ping
Watch the logs while you do it. If you see no Telegram/inbound log at all, it’s likely Telegram polling/token/webhook side. If you do see the inbound message but no reply, paste the log block from that exact moment here.
Also worth checking pairing, since Telegram DMs default to pairing:
openclaw pairing list telegram
Docs for the Telegram access/pairing bits: https://docs.openclaw.ai/channels/telegram
carmine kelp
Great, I got my PONG, although it took maybe 20 seconds, could just be the fresh load?
vestal hatchBOT
Great, I got my PONG, although it took maybe 20 seconds, could just be the fresh...
Yep, that can be normal after a restart/downgrade: first turn may pay for gateway warm-up, channel startup, model/auth initialization, and session loading. The important part is that Telegram inbound + outbound delivery are working again.
I’d do one more quick check: send another short ping now. If it’s much faster, call it recovered. If every tiny message keeps taking ~20s, then grab the log block around one slow turn and we can look for what phase is eating the time.
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes the recovery path for the next person.
carmine kelp
Yeah, around 4 seconds, but what issues can I expect from 5.7? Would it not be advisable to just downgrade to what is really stable, or should 5.7 be stable?
vestal hatchBOT
Yeah, around 4 seconds, but what issues can I expect from 5.7? Would it not be a...
4s sounds healthy enough for a normal tiny turn.
2026.5.7 is a stable npm release, not a beta. I would treat it as a reasonable temporary pin if it fixes the Telegram non-reply issue. I would not keep walking backward unless you hit a specific bug on 5.7, because older versions mainly mean you lose newer fixes, security hardening, channel fixes, and config migrations get less comfortable.
The tradeoff is simple:
2026.5.7 for now if Telegram is working and you need reliability tonight.2026.5.12 on this machine since it reproduced the no-reply behavior for you.openclaw update --dry-run first, then openclaw update.If you want to be extra tidy, note your pin somewhere and periodically check:
openclaw update status
npm view openclaw dist-tags
Update/rollback docs: https://docs.openclaw.ai/install/updating
carmine kelp
Making notes of:
OpenClaw update status
┌──────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ available · pnpm · npm update 2026.5.12 │
└──────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Update available (npm 2026.5.12). Run: openclaw update
and also
{ latest: '2026.5.12', beta: '2026.5.16-beta.4' }
I thank you for the downgrade and assistance - Somehow I'm not looking forward to come back - Joking, good to know where to come for help.
Will mark this as Solved, correct?
vestal hatchBOT
Making notes of:
OpenClaw update status
┌──────────┬───────────────────────────...
Yep, mark it solved. The key recovery note is: 2026.5.12 was latest/stable but stopped replying for your Telegram setup; pinning/downgrading to 2026.5.7 restored replies.
For now, ignore the openclaw update hint unless you intentionally want to test 2026.5.12 again. Your useful future command is the explicit pin, not plain update:
openclaw update --tag 2026.5.7 --yes
And when a newer stable than 2026.5.12 appears, then it’s reasonable to try updating again.
Glad we got you unstuck. Hopefully you only come back for fun stuff next time 🦞