#bot not replying after updating to latest version 2026.04.24

1 messages · Page 1 of 1 (latest)

lavish talon
#

gateway showing the following:
14:03:20 [gateway] starting HTTP server...
14:03:20 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root F:\openclaw-state\canvas)
14:03:20 [discovery] gateway discovery service failed (bonjour, plugin=bonjour): Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@homebridge/ciao' imported from F:\openclaw-state\plugin-runtime-deps\openclaw-2026.4.24-cd6844838215\dist\extensions\bonjour\index.js
14:03:20 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
14:03:23 [gateway] agent model: minimax-portal/MiniMax-M2.7
14:03:23 [gateway] ready (8 plugins: acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice, telegram; 222.1s)
14:03:23 [gateway] log file: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-27.log
14:03:23 [gateway] starting channels and sidecars...
14:04:44 [model-pricing] OpenRouter pricing fetch failed (timeout 30s): TimeoutError: The operation was aborted due to timeout
14:04:44 [model-pricing] LiteLLM pricing fetch failed (timeout 30s): TimeoutError: The operation was aborted due to timeout

tawny umbraBOT
#

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

frigid stratusBOT
#

That OpenRouter/LiteLLM pricing fetch failed part is harmless — it just couldn’t refresh price metadata.

The real red flag is:

Cannot find package '@homebridge/ciao'
... plugin-runtime-deps\openclaw-2026.4.24...

This looks like the 2026.4.24 bundled plugin runtime-deps issue. Stable latest is still 2026.4.24; beta has newer fixes.

Try this first:

openclaw doctor --fix
openclaw gateway restart
#

If it still doesn’t reply, either:

pnpm add -g openclaw@beta
openclaw doctor --fix
openclaw gateway restart

or, as a workaround if you don’t need LAN discovery/Bonjour:

openclaw plugins disable bonjour
openclaw gateway restart

Then paste:

lavish talon
#

after i have ran the doctor --fix command and restarting the gateway, opeonclaw still is not responding. and this is gateway log:
17:02:37 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root F:\openclaw-state\canvas)
17:02:37 [discovery] gateway discovery service failed (bonjour, plugin=bonjour): Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@homebridge/ciao' imported from F:\openclaw-state\plugin-runtime-deps\openclaw-2026.4.24-cd6844838215\dist\extensions\bonjour\index.js
17:02:38 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
17:02:40 [gateway] agent model: minimax-portal/MiniMax-M2.7
17:02:40 [gateway] ready (8 plugins: acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice, telegram; 280.8s)
17:02:40 [gateway] log file: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-27.log
17:02:40 [gateway] starting channels and sidecars...
17:02:40 [gateway] removed stale session lock: F:\openclaw-state\agents\scout\sessions\7fe82af2-d23f-4060-abab-275e97e4c70e.jsonl.lock (dead-pid)
17:04:01 [model-pricing] OpenRouter pricing fetch failed (timeout 30s): TimeoutError: The operation was aborted due to timeout
17:04:01 [model-pricing] LiteLLM pricing fetch failed (timeout 30s): TimeoutError: The operation was aborted due to timeout

frigid stratusBOT
#

The Bonjour error is still real, but it probably isn’t the reason Discord isn’t replying. Bigger clue: your “ready” line lists:

acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice, telegram

I don’t see discord loaded at all. So OpenClaw may be running, but the Discord channel isn’t active / configured / token-visible.

Do these in order:

openclaw --version
openclaw channels status --probe
openclaw channels list

If Discord is missing or says token unavailable, re-check Discord config/token — don’t paste the token here. You can re-add it locally with:

lavish talon
#

it's not discord, openclaw isn't replying to me on telegram at all. and i am seeing the below errors in gateway:
17:58:36 [plugins] xai staging bundled runtime deps (3 missing, 67 install specs): @mariozechner/pi-ai@0.70.2, typebox@1.1.31, ws@^8.20.0
17:58:54 [plugins] xai installed bundled runtime deps in 18582ms: @mariozechner/pi-ai@0.70.2, typebox@1.1.31, ws@^8.20.0
17:58:56 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
17:58:56 [telegram] [default] channel stop exceeded 5000ms after abort; continuing shutdown
17:58:58 [telegram] setMyCommands failed: Network request for 'setMyCommands' failed!
17:58:58 [telegram] command sync failed: HttpError: Network request for 'setMyCommands' failed!

frigid stratusBOT
#

Got it — thanks, that changes the diagnosis. If Telegram isn’t replying, focus on this line:

[telegram] setMyCommands failed: Network request for 'setMyCommands' failed!

That means the Gateway cannot reach Telegram’s Bot API from the machine/process running OpenClaw. The other lines are mostly noise:

  • xai staging bundled runtime deps... installed = repair/install step, okay if it completed.
  • memory-core ... cron service unavailable = not a chat reply blocker.
  • telegram channel stop exceeded... = happened during shutdown/restart.

Please run these and paste the redacted output:

openclaw --version
# 
openclaw status --all
openclaw channels status --probe
openclaw channels logs --channel telegram --lines 120

Also test network access to Telegram from the same machine. In PowerShell, if your token is in env:

$token = $env:TELEGRAM_BOT_TOKEN
Invoke-RestMethod "https://api.telegram.org/bot$token/getMe"

If that fails, it’s network/proxy/firewall/DNS/VPN — not an OpenClaw config issue. If you use a proxy/VPN, make sure the Gateway process sees the proxy env too, not just your terminal.

Docs: https://docs.openclaw.ai/channels/telegram and https://docs.openclaw.ai/channels/troubleshooting

vital bobcat
frigid stratusBOT
#

Yep — that does line up with the 2026.4.24 bundled runtime-deps regression. Issue #72270 specifically reports Telegram becoming inoperable from plugin dependency staging failures in 2026.4.24, with rollback as a sane workaround while waiting for the fixed release. (github.com)

For Gly, I’d stop fighting .24 and either:

pnpm add -g openclaw@2026.4.23
openclaw doctor --fix
openclaw gateway restart

or, if they’re comfortable testing the fix before stable:

pnpm add -g openclaw@beta
openclaw doctor --fix
openclaw gateway restart
GitHub
Issues · openclaw/openclaw

Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 - Issues · openclaw/openclaw

#

After rollback/update, check:

openclaw --version
openclaw channels status --probe

If Telegram still fails after that, then we can dig into the network setMyCommands error separately — but given .24, rollback/beta is the fastest next move.

lavish talon
frigid stratusBOT
#

Yep — rollback should be straightforward:

openclaw gateway stop
pnpm add -g openclaw@2026.4.23
openclaw --version
openclaw doctor --fix
openclaw gateway start

Then check Telegram:

openclaw channels status --probe

If you still see it loading openclaw-2026.4.24-... after rollback, restart the whole machine once — that usually clears any stuck old gateway process/path. 2026.4.23 does exist on npm.

vital bobcat
lavish talon
#

thanks for the early heads up! @vital bobcat
I would have spent like an hour or fixing this just now..

frigid stratusBOT
#

Glad we caught it before the rabbit hole 🦐

After the rollback, if Telegram replies again, please mark the rollback/instructions message as the solution so Answer Overflow indexes it for the next person:
right-click the solution message → Apps → ✅ Mark Solution.

lavish talon
#

after i have rolledo back to version 2026.4.23 and restarted the gateway, i am still seeing the below error in the gateway:
19:10:31 [telegram] [default] starting provider (@glyclawdbot)
19:11:00 [bonjour] restarting advertiser (service stuck in announcing for 34198ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
19:11:15 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=unannounced)
19:11:15 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw-state\workspace-main)
19:11:15 (node:12408) [DEP0190] DeprecationWarning: Passing args to a child process with shell option true can lead to security vulnerabilities, as the arguments are not escaped, only concatenated.
19:11:15 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
19:11:17 [plugins] memory-core: updated managed dreaming cron job.
19:11:46 [bonjour] restarting advertiser (service stuck in probing for 30848ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing))
19:11:46 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
19:11:46 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.33s.
19:11:46 [plugins] embedded acpx runtime backend ready
19:12:06 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
19:12:28 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
19:12:28 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 4.13s.
[session-write-lock] releasing lock held for 82246ms (max=15000ms): F:\openclaw-state\agents\fintech\sessions\sessions.json.lock

frigid stratusBOT
#

Good news: the rollback probably did fix the .24 plugin-deps problem — the old @homebridge/ciao missing-package error is gone.

Now this is a different blocker:

[telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!

That means OpenClaw can load the Telegram channel, but the Gateway process cannot reach Telegram’s Bot API (api.telegram.org) reliably. Bonjour warnings are noisy but not the Telegram blocker.

Please test from the same Windows machine running the Gateway:

$token = "YOUR_TELEGRAM_BOT_TOKEN"   # local only, don't paste it here
Invoke-RestMethod "https://api.telegram.org/bot$token/getMe"
Invoke-RestMethod "https://api.telegram.org/bot$token/deleteWebhook"
#

Also:

Resolve-DnsName api.telegram.org
Test-NetConnection api.telegram.org -Port 443

If those fail, check VPN/proxy/firewall/DNS. If they pass, run:

openclaw channels status --probe
openclaw channels logs --channel telegram --lines 120

Optional cleanup so Bonjour stops distracting the logs:

lavish talon
#

now the gateway won't even start, it is returning the below error in powershell:
PS C:\Windows\system32> openclaw gateway start
node:internal/modules/cjs/loader:1386
throw err;
^

Error: Cannot find module 'F:\npm-global\node_modules\openclaw\openclaw.mjs'
at Function._resolveFilename (node:internal/modules/cjs/loader:1383:15)
at defaultResolveImpl (node:internal/modules/cjs/loader:1025:19)
at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1030:22)
at Function._load (node:internal/modules/cjs/loader:1192:37)
at TracingChannel.traceSync (node:diagnostics_channel:328:14)
at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
at node:internal/main/run_main_module:36:49 {
code: 'MODULE_NOT_FOUND',
requireStack: []
}

Node.js v22.22.2

frigid stratusBOT
#

That error means the CLI install itself is broken/stale now — Windows is finding an openclaw shim that points at:

F:\npm-global\node_modules\openclaw\openclaw.mjs

…but that file isn’t there.

Repair the global install first:

where.exe openclaw
pnpm remove -g openclaw
pnpm add -g openclaw@2026.4.23
openclaw --version
#

If openclaw --version still throws the same F:\npm-global\node_modules... error, you have a stale Windows shim earlier in PATH. Check:

where.exe openclaw

Then rename/delete the stale files it shows, usually something like:

Rename-Item F:\npm-global\openclaw.cmd openclaw.cmd.bak
Rename-Item F:\npm-global\openclaw.ps1 openclaw.ps1.bak

Then reinstall again:

# 
pnpm add -g openclaw@2026.4.23
openclaw --version
openclaw gateway start

Once the CLI starts again, we can continue with the Telegram deleteWebhook network issue if it’s still happening.

lavish talon
#

telegram is back now, but it is not really replying, gateway is showing:
19:27:07 [gateway] starting channels and sidecars...
19:27:07 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=unannounced)
19:32:25 [bonjour] restarting advertiser (service stuck in probing for 317512ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing))
19:32:25 [model-pricing] OpenRouter pricing fetch failed (timeout 30s): TimeoutError: The operation was aborted due to timeout
19:32:25 [model-pricing] LiteLLM pricing fetch failed (timeout 30s): TimeoutError: The operation was aborted due to timeout
19:32:31 [health-monitor] [telegram:default] health-monitor: restarting (reason: stopped)
19:32:31 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
19:32:32 [gateway] removed stale session lock: F:\openclaw-state\agents\main\sessions\7e8ac155-b508-4be8-9748-47edf3801041.jsonl.lock (dead-pid)
19:32:32 [gateway] removed stale session lock: F:\openclaw-state\agents\scout\sessions\46b560e8-2a05-49a6-b76d-0bf86dc2644e.jsonl.lock (dead-pid)
19:34:10 [telegram] [default] starting provider
19:34:10 [bonjour] restarting advertiser (service stuck in announcing for 99477ms (gateway fqdn=LPA (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))

frigid stratusBOT
#

Progress: this no longer looks like the .24 dependency failure. Now the important line is:

[health-monitor] [telegram:default] restarting (reason: stopped)

So Telegram starts, then the channel stops or stalls.

Quick split-test:

  1. DM your Telegram bot this exact message:
/status

/status should bypass the model.

#
  • If /status replies → Telegram channel works; problem is agent/model/session.
  • If /status does not reply → channel/pairing/network is still broken.

Then paste:

openclaw channels status --probe
openclaw health --verbose
openclaw channels logs --channel telegram --lines 200

Also disable Bonjour now — it’s not the Telegram blocker, but it’s making the logs noisy:

openclaw plugins disable bonjour
openclaw gateway restart
#

If Telegram keeps being restarted by the health monitor while testing, you can temporarily stop that restart loop:

openclaw config set channels.telegram.healthMonitor.enabled false --strict-json
openclaw gateway restart

But grab the Telegram logs first if you can; they’ll show why it stopped.

lavish talon
#

ran openclaw doctor --fix command and the gateway is still crashing nonstop, troubleshoot with me.
| Runtime: stopped (state Ready, last run 1, last run time 4/27/2026 11:39:45 PM, Task |
| Last Run Result=1; treating as not running.) |
| Service is loaded but not running (likely exited immediately). |
| File logs: C:\Users\glysh\AppData\Local\Temp\openclaw\openclaw-2026-04-27.log |
| Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST |
| Restart attempts: F:\openclaw-state\logs\gateway-restart.log |

frigid stratusBOT
#

Yep, let’s isolate the crash first. Last Run Result=1 just means “the scheduled task exited with error”; the real stack trace should be in the restart/log files.

Run these in PowerShell and paste the output, redacting tokens:

openclaw --version
where.exe openclaw
Get-Command openclaw | Format-List Source,Definition
Get-Content "F:\openclaw-state\logs\gateway-restart.log" -Tail 120
Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-27.log" -Tail 200

Then stop the service loop and run Gateway in the foreground so we can see the actual crash:

openclaw gateway stop
# 
cd $HOME
openclaw --log-level debug gateway run --force

Paste the first fatal error/stack trace from that foreground run.

My suspicion: after the rollback/reinstall dance, the Windows scheduled task may still point at a stale/broken global install path. If the foreground run works but the service crashes, fix the task with:

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway start

But don’t do that yet if foreground also crashes — then we need the stack trace first. Docs for this path: https://docs.openclaw.ai/cli/gateway

lavish talon
#

OpenClaw 2026.4.24 (cbcfdf6)
F:\npm-global\openclaw
F:\npm-global\opencPS C:\Windows\system32> openclaw --version

where.exe openclaw
Get-Command openclaw | Format-List Source,Definition
Get-Content "F:\openclaw-state\logs\gateway-restart.log" -Tail 120
Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-27.log" -Tail 200
OpenClaw 2026.4.24 (cbcfdf6)
F:\npm-global\openclaw
F:\npm-global\openclaw.cmd

Source : F:\npm-global\openclaw.ps1
Definition : F:\npm-global\openclaw.ps1

Get-Content : Cannot find path 'F:\openclaw-state\logs\gateway-restart.log' because it does not exist.
At line:4 char:1

  • Get-Content "F:\openclaw-state\logs\gateway-restart.log" -Tail 120
  •   + CategoryInfo          : ObjectNotFound: (F:\openclaw-sta...way-restart.log:String) [Get-Content], ItemNotFoundEx
 ception
  + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetContentCommand

law.cmd

Source : F:\npm-global\openclaw.ps1
Definition : F:\npm-global\openclaw.ps1

frigid stratusBOT
#

Aha — this is the key:

OpenClaw 2026.4.24 (cbcfdf6)

So the rollback didn’t actually take. You’re still running .24, from:

F:\npm-global\openclaw.ps1
F:\npm-global\openclaw.cmd

Don’t troubleshoot the gateway yet — first get openclaw --version to say 2026.4.23.

Try:

# 
openclaw gateway stop
pnpm remove -g openclaw
pnpm add -g openclaw@2026.4.23 --force
openclaw --version
where.exe openclaw

If it still says 2026.4.24, rename the stale shims and reinstall:

Rename-Item F:\npm-global\openclaw.ps1 openclaw.ps1.bak -Force
Rename-Item F:\npm-global\openclaw.cmd openclaw.cmd.bak -Force
Rename-Item F:\npm-global\openclaw openclaw.bak -Force

pnpm add -g openclaw@2026.4.23 --force
# 
openclaw --version
where.exe openclaw

Only once that prints OpenClaw 2026.4.23, run:

openclaw doctor --fix
openclaw gateway install --force
openclaw gateway start
openclaw gateway status

The missing gateway-restart.log is secondary. The main blocker is: your PATH is still launching .24.

lavish talon
#

i am using npm install instead of pnpm, give me the right commands to troubleshoot with

frigid stratusBOT
#

Yep — use npm equivalents.

First make sure the service is stopped:

openclaw gateway stop

Then force reinstall the known-good version:

npm uninstall -g openclaw
npm install -g openclaw@2026.4.23 --force
openclaw --version
where.exe openclaw
#

If openclaw --version still says 2026.4.24, remove the stale shims manually and reinstall:

Rename-Item F:\npm-global\openclaw.ps1 openclaw.ps1.bak -Force
Rename-Item F:\npm-global\openclaw.cmd openclaw.cmd.bak -Force
Rename-Item F:\npm-global\openclaw openclaw.bak -Force

npm install -g openclaw@2026.4.23 --force
openclaw --version
where.exe openclaw

Once it shows OpenClaw 2026.4.23, repair/reinstall the Windows scheduled task:

openclaw doctor --fix
# 
openclaw gateway install --force
openclaw gateway start
openclaw gateway status

If that still crashes, run foreground mode:

openclaw gateway stop
openclaw --log-level debug gateway run --force

Paste the first fatal error from that foreground run.

lavish talon
#

i have successfully upgraded to 2026.4.25 (latest version), and since i am still not getting any response frlom telegram,i am seeing the below error in the gateway still:
00:56:14 [plugins] web-readability installed bundled runtime deps in 9363ms: @mozilla/readability@^0.6.0, linkedom@^0.18.12
01:04:08 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=469s queueDepth=101:04:08 [telegram] Polling stall detected (active getUpdates stuck for 369.96s); forcing restart. [diag inFlight=1 outcome=started startedAt=1777309078503 finishedAt=1777309077760 durationMs=95776 offset=676699003]
01:04:08 [telegram] [diag] polling cycle finished reason=polling stall detected inFlight=0 outcome=error startedAt=1777309078503 finishedAt=1777309448466 durationMs=369963 offset=676699003 error=Network request for 'getUpdates' failed!
01:04:08 [telegram] polling runner stopped (polling stall detected); restarting in 2.32s.
01:04:08 typing TTL reached (2m); stopping typing indicator
01:04:09 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
01:04:09 [telegram] telegram slash final reply failed: HttpError: Network request for 'sendMessage' failed!
01:04:09 [telegram] sendChatAction failed: Network request for 'sendChatAction' failed!
01:04:10 [telegram] [diag] closing stale transport before rebuild
01:04:10 [telegram] [diag] rebuilding transport for next polling cycle
01:04:11 [telegram] sendChatAction failed: Network request for 'sendChatAction' failed!
01:04:25 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
01:04:25 [telegram] telegram final reply failed: HttpError: Network request for 'sendMessage' failed!
01:04:26 [telegram] sendMessage failed: Network request for 'sendMessage' failed!
01:04:26 [telegram] telegram message processing failed: HttpError: Network request for 'sendMessage' failed!

frigid stratusBOT
#

Good, 2026.4.25 is current latest now. This is no longer the .24 dependency bug — every failing line is Telegram network I/O:

getUpdates failed
sendMessage failed
sendChatAction failed

So let’s prove whether Node/OpenClaw can reach Telegram.

Don’t paste your bot token. Run locally:

$token = "YOUR_TELEGRAM_BOT_TOKEN"

node -e "const t=process.argv[1]; fetch('https://api.telegram.org/bot'+t+'/getMe',{signal:AbortSignal.timeout(15000)}).then(async r=>{console.log(r.status); console.log(await r.text())}).catch(e=>{console.error(e.name,e.code,e.cause?.code,e.message); process.exit(1)})" $token
# 

Resolve-DnsName api.telegram.org
Test-NetConnection api.telegram.org -Port 443
curl.exe -4 -v "https://api.telegram.org/bot$token/getMe"

Then run OpenClaw foreground with Telegram diagnostics:

openclaw gateway stop
$env:OPENCLAW_DIAGNOSTICS="telegram.http"
openclaw --log-level debug gateway run --force

Send one Telegram message, then paste the Telegram-related errors.

#

If the node fetch test fails or hangs, try forcing Telegram to IPv4/direct behavior:

openclaw config set channels.telegram.network.dnsResultOrder '"ipv4first"' --strict-json
openclaw config set channels.telegram.network.autoSelectFamily false --strict-json
openclaw gateway restart

If you use a proxy/VPN, configure Telegram explicitly instead of relying on shell env:

openclaw config set channels.telegram.proxy "http://127.0.0.1:7890"
openclaw gateway restart

If your config uses channels.telegram.accounts.default, use:

lavish talon
#

after running --log-level debug gateway and sending a telegram message to verify, i am seeing the below errors:
01:36:28 [diagnostic] message queued: sessionId=unknown sessionKey=agent:main:main source=dispatch queueDepth=1 sessionState=idle
01:36:28 [diagnostic] session state: sessionId=unknown sessionKey=agent:main:main prev=idle new=processing reason="message_start" queueDepth=1
01:36:28 [plugins] [hooks] running reply_dispatch (1 handlers, first-claim wins)
01:36:28 [diagnostic] heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
01:36:31 [plugins] [hooks] running before_agent_reply (1 handlers, first-claim wins)
01:36:42 [diagnostic] lane enqueue: lane=session:agent:main:main queueSize=1
01:36:46 [diagnostic] lane wait exceeded: lane=session:agent:main:main waitedMs=3593 queueAhead=0
01:36:46 [diagnostic] lane dequeue: lane=session:agent:main:main waitMs=3593 queueSize=0
01:36:46 [diagnostic] lane enqueue: lane=main queueSize=1
01:36:46 [diagnostic] lane dequeue: lane=main waitMs=3 queueSize=0
01:37:50 [diagnostic] heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
01:39:07 [diagnostic] heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
01:39:07 [diagnostic] stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=160s queueDepth=1
01:39:07 typing TTL reached (2m); stopping typing indicator
01:39:08 [agents/harness] agent harness selected
01:39:08 [agent/embedded] embedded run start: runId=0d34a4f1-37c8-4100-a138-dbff09af6271 sessionId=7e8ac155-b508-4be8-9748-47edf3801041 provider=minimax-portal model=MiniMax-M2.7 thinking=medium messageChannel=telegram

frigid stratusBOT
#

This is useful: Telegram is receiving messages now. The log shows the message enters OpenClaw and gets queued:

message queued ... sessionState=idle
session state ... new=processing
...
embedded run start ... provider=minimax-portal model=MiniMax-M2.7

So the current blocker is agent/model execution, not Telegram ingress.

Please do these next:

openclaw models status --probe
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
#

If infer model run hangs or fails, the default model/provider is the issue. Temporarily switch to any known-good configured model:

openclaw models list
openclaw models set <provider/model>
openclaw gateway restart

Then test Telegram again.

Also paste the log lines after this line:

[agent/embedded] embedded run start...

That’s where the real model/provider error should appear. Use:

# 
Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-27.log" -Tail 300

The key shift: Telegram is no longer the first problem; the agent is starting but not producing a final reply.

lavish talon
#

Config : F:\openclaw-state\openclaw.json
Agent dir : F:\openclaw-state\agents\main\agent
Default : minimax-portal/MiniMax-M2.7
Fallbacks (2) : minimax-portal/MiniMax-M2.5, minimax-portal/MiniMax-M2.1
Image model : -
Image fallbacks (0): -
Aliases (4) : minimax-m2.1 -> minimax-portal/MiniMax-M2.1, minimax-m2.5 -> minimax-portal/MiniMax-M2.5, minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (6): minimax/MiniMax-M2.5-Lightning, minimax/MiniMax-M2.5, minimax-portal/MiniMax-M2.1, minimax-portal/MiniMax-M2.5, minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed

Auth overview
Auth store : F:\openclaw-state\agents\main\agent\auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): minimax-portal (1), qwen-portal (1)

  • minimax effective=profiles:F:\openclaw-state\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | minimax:default=
  • minimax-portal effective=profiles:F:\openclaw-state\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth | models.json=marker(minimax-oauth) | source=models.json: F:\openclaw-state\agents\main\agent\models.json
  • qwen-portal effective=profiles:F:\openclaw-state\agents\main\agent\auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | qwen-portal:default=OAuth

OAuth/token status

  • minimax-portal
    • minimax-portal:default ok expires in 306d
  • qwen-portal
    • qwen-portal:default expired expires in 0m

Auth probes
| minimax/MiniMax-M2.5- | minimax:default (api_ | auth · 279.7s
| Lightning | key) | ↳ HTTP 401 authentication_error: token is unusable inimax-portal:default | ok · 272.6s |
| M2.7 | (oauth) |
| qwen-portal/coder-model | qwen-portal:default | auth · 243.4s | ↳ No credentials found for profile "qwen-portal:default". |s

frigid stratusBOT
#

This points at the model layer now, not Telegram.

Key bit:

minimax-portal/MiniMax-M2.7 ... ok · 272.6s

That means the default model auth works, but the probe took ~4.5 minutes. So Telegram receives your message, queues it, starts the agent, then the model call is painfully slow / timing out-ish.

Two bad auth entries are also present:

  • minimax API key → HTTP 401 token is unusable
  • qwen-portal → expired / no credentials

Next steps:

# 
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If that also takes minutes, switch to a faster known-good configured model/provider, then restart:

openclaw models set <provider/model>
openclaw gateway restart

You can also remove/refresh the broken auth profiles later, but first prove replies work with a healthy model.

For fresh model recommendations, ask in #models — the working/fast choices change too quickly for me to safely recommend one from memory.

lavish talon
#

PS C:\Windows\system32> openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "minimax-portal",
"model": "MiniMax-M2.7",
"attempts": [],
"outputs": [
{
"text": "smoke-ok",
"mediaUrl": null
}
]
}

frigid stratusBOT
#

Nice — that proves MiniMax itself works. But that command used:

"transport": "local"

Local infer is the lean path; Telegram uses the Gateway agent runtime, so test that exact path next:

openclaw infer model run --gateway --prompt "Reply with exactly: smoke-ok" --json

Then:

If --gateway succeeds

Telegram/session state is likely stuck. In Telegram send:

# 
/status

then:

/new

or:

/reset

Then send a normal message.

#

If --gateway hangs/fails

Paste the error plus the log after:

[agent/embedded] embedded run start...

Use:

Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-27.log" -Tail 400

The key distinction: provider auth is okay; now we’re narrowing whether the Gateway runtime/session path is stuck.

lavish talon
#

PS C:\Windows\system32> openclaw infer model run --gateway --prompt "Reply with exactly: smoke-ok" --json
Error: gateway timeout after 120000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: F:\openclaw-state\openclaw.json
Bind: loopback

frigid stratusBOT
#

That confirms it: local model works, but the Gateway runtime path is wedged. Telegram is just the messenger here.

First try aborting the stuck Gateway session:

  1. In Telegram, send standalone:
/stop
  1. Then send:
/reset
  1. Retest from PowerShell:
# 
openclaw infer model run --gateway --prompt "Reply with exactly: smoke-ok" --json

If it still times out, restart the gateway and test before sending any more Telegram messages:

openclaw gateway restart
openclaw infer model run --gateway --prompt "Reply with exactly: smoke-ok" --json

If that still times out, paste:

openclaw gateway status
Get-Content "$env:LOCALAPPDATA\Temp\openclaw\openclaw-2026-04-27.log" -Tail 500
#

No more doctor --fix for now — it already proved install/config isn’t the current blocker. We need to catch why the Gateway agent runtime isn’t completing.

lavish talon
#

{"fullFilePath":"file:///F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337:14","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:337","fileColumn":"14","fileLine":"337","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:337","method":"logToFile"}},"time":"2026-04-27T23:52:51.174+08:00"}
{"0":"[openclaw] Unhandled promise rejection: CIAO PROBING CANCELLED","meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"openclaw","date":"2026-04-27T15:52:51.183Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy.js:161:68","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:161","fileColumn":"68","fileLine":"161","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:161","method":"console.error"}},"time":"2026-04-27T23:52:51.185+08:00"}
{"0":"[openclaw] wrote stability bundle: F:\openclaw-state\logs\stability\openclaw-stability-2026-04-27T15-52-51-189Z-2400-unhandled_rejection.json","meta":{"runtime":"node","runtimeVersion":"24.13.1","hostname":"LPA","name":"openclaw","date":"2026-04-27T15:52:51.196Z","logLevelId":5,"logLevelName":"ERROR","path":{"fullFilePath":"file:///F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy.js:161:68","fileName":"subsystem-CWI_MDy_.js","fileNameWithLine":"subsystem-CWI_MDy_.js:161","fileColumn":"68","fileLine":"161","filePath":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js","filePathWithLine":"/F:/npm-global/node_modules/openclaw/dist/subsystem-CWI_MDy_.js:161","method":"console.error"}},"time":"2026-04-27T23:52:51.197+08:00"}

frigid stratusBOT
#

That’s the smoking gun:

Unhandled promise rejection: CIAO PROBING CANCELLED

That’s Bonjour/mDNS, not Telegram or MiniMax. Disable Bonjour completely and retest the Gateway path.

Run:

openclaw gateway stop
openclaw plugins disable bonjour
openclaw plugins list --enabled
openclaw gateway restart
#

Then verify Bonjour is gone from the startup “ready plugins” list, and test:

openclaw infer model run --gateway --prompt "Reply with exactly: smoke-ok" --json

If it still crashes, do a one-off foreground run with the env override too:

openclaw gateway stop
$env:OPENCLAW_DISABLE_BONJOUR="1"
openclaw --log-level debug gateway run --force

If that fixes it, the bug is specifically Bonjour/CIAO on your Windows network. Please file the stability bundle path in a GitHub issue:

lavish talon
#

09:52:25 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
09:52:25 [telegram] [default] starting provider
09:52:26 [telegram] autoSelectFamily=true (default-node22)
09:52:26 [telegram] dnsResultOrder=ipv4first (default-node22)
09:52:27 [skills] Sanitized skill command name "node-connect" to "/node_connect".
09:52:27 [skills] Sanitized skill command name "skill-creator" to "/skill_creator".
09:52:27 [skills] Sanitized skill command name "taskflow-inbox-triage" to "/taskflow_inbox_triage".
09:52:27 [heartbeat] started
09:52:27 [plugins] [hooks] running gateway_start (1 handlers)
09:53:09 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
09:53:09 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 2.26s.
09:53:09 [codex/catalog] codex model discovery failed; using fallback catalog
09:54:04 [telegram] deleteWebhook failed: Network request for 'deleteWebhook' failed!
09:54:04 [telegram] webhook cleanup failed: Network request for 'deleteWebhook' failed!; retrying in 4.2s.
09:54:06 [diagnostic] lane enqueue: lane=session:agent:analyst:cron:analyst-2-strategic-router queueSize=1
09:54:06 [diagnostic] lane dequeue: lane=session:agent:analyst:cron:analyst-2-strategic-router waitMs=3 queueSize=0
09:54:06 [diagnostic] lane enqueue: lane=nested queueSize=1
09:54:06 [diagnostic] lane dequeue: lane=nested waitMs=3 queueSize=0
09:55:45 [plugins] [hooks] running before_agent_reply (1 handlers, first-claim wins)
09:55:47 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
09:58:25 [health-monitor] [telegram:default] health-monitor: restarting (reason: disconnected)
09:58:26 [agents/harness] agent harness selected
09:58:26 [agent/embedded] embedded run start: runId=09b96235-eef7-46e0-8a57-d17eaa259601 sessionId=09b96235-eef7-46e0-8a57-d17eaa259601 provider=minimax-portal model=MiniMax-M2.7 thinking=medium messageChannel=telegram

frigid stratusBOT
#

This log is back to a Telegram Bot API network failure:

deleteWebhook failed: Network request for 'deleteWebhook' failed!
health-monitor: restarting (reason: disconnected)

So the provider starts, but it can’t reliably talk to api.telegram.org, so polling never becomes healthy.

Please run these from the same PowerShell where you start the gateway, and paste results without the token:

$token = "YOUR_TELEGRAM_BOT_TOKEN"

node -e "fetch('https://api.telegram.org/bot'+process.argv[1]+'/deleteWebhook',{signal:AbortSignal.timeout(20000)}).then(async r=>{console.log('status',r.status); console.log(await r.text())}).catch(e=>{console.error(e.name,e.code,e.cause?.code,e.message); process.exit(1)})" $token
# 
curl.exe -4 -v "https://api.telegram.org/bot$token/deleteWebhook"
Resolve-DnsName api.telegram.org
Test-NetConnection api.telegram.org -Port 443

If those fail/hang, fix VPN/proxy/firewall/DNS first. If curl works but Node/OpenClaw fails, set Telegram proxy explicitly:

openclaw config set channels.telegram.proxy "http://127.0.0.1:YOUR_PROXY_PORT"
openclaw gateway restart

Also temporarily quiet the restart loop while testing:

# 
openclaw config set channels.telegram.healthMonitor.enabled false --strict-json
openclaw gateway restart

Then re-enable it after Telegram is stable.

lavish talon
#

{"ok":true,"result":true,"description":"Webhook is already deleted"}

and what i am seeing in the gateway now:
11:13:09 [telegram] [default] starting provider
11:13:13 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw-state\workspace-main)
11:13:16 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
11:13:16 [heartbeat] started
11:24:28 [telegram] Polling stall detected (active getUpdates stuck for 129.12s); forcing restart. [diag inFlight=1 outcome=started startedAt=1777346539335 finishedAt=1777346539329 durationMs=22659 offset=676699008]
11:24:28 [telegram] [diag] polling cycle finished reason=polling stall detected inFlight=0 outcome=error startedAt=1777346539335 finishedAt=1777346668466 durationMs=129131 offset=676699008 error=Network request for 'getUpdates' failed!
11:24:28 [telegram] polling runner stopped (polling stall detected); restarting in 2.11s.
11:24:30 [telegram] [diag] closing stale transport before rebuild
11:24:30 [telegram] [diag] rebuilding transport for next polling cycle
11:24:49 [telegram] sendChatAction failed: Network request for 'sendChatAction' failed!

frigid stratusBOT
#

Good, that proves short Telegram API calls work. The thing still failing is the long-poll path:

getUpdates stuck / failed
sendChatAction failed

So test the exact failing call, with Gateway stopped so there’s no competing poller:

openclaw gateway stop
$token = "YOUR_TELEGRAM_BOT_TOKEN"

node -e "fetch('https://api.telegram.org/bot'+process.argv[1]+'/getUpdates?timeout=30',{signal:AbortSignal.timeout(45000)}).then(async r=>{console.log('status',r.status); console.log(await r.text())}).catch(e=>{console.error(e.name,e.code,e.cause?.code,e.message); process.exit(1)})" $token

Also check for proxy env differences:

# 
Get-ChildItem Env:*PROXY*
openclaw config get channels.telegram.proxy

If you’re not intentionally using a proxy, try a clean foreground run with proxy env cleared:

Remove-Item Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:http_proxy,Env:https_proxy,Env:NO_PROXY,Env:no_proxy -ErrorAction SilentlyContinue
$env:OPENCLAW_DIAGNOSTICS="telegram.http"
openclaw --log-level debug gateway run --force

If you are using VPN/proxy, set Telegram explicitly:

# 
openclaw config set channels.telegram.proxy "http://127.0.0.1:YOUR_PROXY_PORT"
openclaw gateway restart

If the clean foreground run works but the service does not, reinstall the scheduled task so it doesn’t keep stale env:

openclaw gateway install --force
openclaw gateway start

Don’t tune stall thresholds yet — that would only hide the symptom. The target is making getUpdates and sendChatAction reliable.

lavish talon
#

PS C:\Windows\system32> Get-ChildItem Env:PROXY

openclaw config get channels.telegram.proxy

🦞 OpenClaw 2026.4.25 (aa36ee6) — If you can describe it, I can probably automate it—or at least make it funnier.

Config path not found: channels.telegram.proxy

frigid stratusBOT
#

That output means:

  • No *PROXY* env vars printed → likely no proxy env in that shell.
  • channels.telegram.proxy missing → no explicit Telegram proxy configured.

Now run the exact long-poll test — this is the important one:

openclaw gateway stop
$token = "YOUR_TELEGRAM_BOT_TOKEN"

node -e "fetch('https://api.telegram.org/bot'+process.argv[1]+'/getUpdates?timeout=30',{signal:AbortSignal.timeout(45000)}).then(async r=>{console.log('status',r.status); console.log(await r.text())}).catch(e=>{console.error(e.name,e.code,e.cause?.code,e.message); process.exit(1)})" $token

If that fails/hangs, it’s your network/ISP/VPN path to Telegram long-polling.

If that succeeds, start OpenClaw cleanly in foreground:

# 
$env:OPENCLAW_DIAGNOSTICS="telegram.http"
$env:OPENCLAW_DISABLE_BONJOUR="1"
openclaw --log-level debug gateway run --force

Then send Telegram a message and watch whether getUpdates fails again.

lavish talon
#

12:09:40 [telegram] [default] starting provider
12:09:43 [telegram] autoSelectFamily=true (default-node22)
12:09:43 [telegram] dnsResultOrder=ipv4first (default-node22)
12:09:45 [skills] Sanitized skill command name "node-connect" to "/node_connect".
12:09:45 [skills] Sanitized skill command name "skill-creator" to "/skill_creator".
12:09:45 [skills] Sanitized skill command name "taskflow-inbox-triage" to "/taskflow_inbox_triage".
12:09:45 [plugins] embedded acpx runtime backend registered (cwd: F:\openclaw-state\workspace-main)
12:09:55 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
12:09:56 [heartbeat] started
12:09:56 [plugins] [hooks] running gateway_start (1 handlers)
12:13:06 [telegram] update: {"update_id":676699008,"message":{"message_id":8942,"from":{"id":98608254,"is_bot":false,"first_name":"k","last_name":"🐱","username":"Glyyy","language_code":"en"},"chat":{"id":98608254,"first_name":"k","last_name":"🐱","username":"Glyyy","type":"private"},"date":1777349585,"text":"ping"}}
12:15:08 [diagnostic] message queued: sessionId=unknown sessionKey=agent:main:main source=dispatch queueDepth=1 sessionState=idle
12:15:08 [diagnostic] session state: sessionId=unknown sessionKey=agent:main:main prev=idle new=processing reason="message_start" queueDepth=1
12:15:08 [plugins] [hooks] running reply_dispatch (1 handlers, first-claim wins)
12:15:09 [diagnostic] heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
12:15:09 [telegram] Polling stall detected (active getUpdates stuck for 122.86s); forcing restart. [diag inFlight=1 outcome=started startedAt=1777349586422 finishedAt=1777349586418 durationMs=6041 offset=676699009]
12:15:09 [telegram] [diag] polling cycle finished reason=polling stall detected inFlight=0 outcome=error startedAt=1777349586422 finishedAt=1777349709325 durationMs=122903 offset=676699009 error=Network request for 'getUpdates' failed!

#

12:15:09 [telegram] polling runner stopped (polling stall detected); restarting in 2.05s.
12:15:11 [telegram] autoSelectFamily=true (default-node22)
12:15:11 [telegram] dnsResultOrder=ipv4first (default-node22)
12:15:11 [telegram] [diag] closing stale transport before rebuild
12:15:11 [telegram] [diag] rebuilding transport for next polling cycle
12:15:15 [plugins] [hooks] running before_agent_reply (1 handlers, first-claim wins)
12:15:29 [telegram] sendChatAction failed: Network request for 'sendChatAction' failed!
12:15:31 [diagnostic] lane enqueue: lane=session:agent:main:main queueSize=1
12:15:31 [diagnostic] lane dequeue: lane=session:agent:main:main waitMs=4 queueSize=0
12:15:31 [diagnostic] lane enqueue: lane=main queueSize=1
12:15:31 [diagnostic] lane dequeue: lane=main waitMs=4 queueSize=0
12:16:55 [diagnostic] heartbeat: webhooks=0/0/0 active=1 waiting=0 queued=1
12:16:56 [agents/harness] agent harness selected
12:16:56 [agent/embedded] embedded run start: runId=692c715d-127a-405f-a894-b7ca068d3fe4 sessionId=37fdb063-20d2-44a4-979d-776a25c10e6f provider=minimax-portal model=MiniMax-M2.7 thinking=medium messageChannel=telegram
12:16:57 [telegram] sendChatAction failed: Network request for 'sendChatAction' failed!

frigid stratusBOT
#

Yep — this looks very likely tied to the 2026.4.24 bundled plugin runtime deps regression, especially this line:

Cannot find package '@homebridge/ciao' ... plugin-runtime-deps\openclaw-2026.4.24...

Also, 2026.4.24 is no longer the latest — current docs/changelog show 2026.4.26.

Try this first:

openclaw --version
openclaw update
openclaw doctor --fix
openclaw gateway restart
openclaw status --all
#

Then DM Telegram ping again.

The getUpdates failed / Polling stall detected part can be network/DNS/proxy noise, but since the update was received and queued, the bigger issue is probably after dispatch / plugin runtime repair.

If it still doesn’t reply after update + doctor, paste the log starting from:

[diagnostic] message queued

through the next model/provider error. Also include:

openclaw channels status --probe

Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/channels/telegram#troubleshooting

#

This confirms two separate things:

  1. The inbound Telegram message reached OpenClaw ✅
    It queued, selected the harness, and started the agent run:
[agent/embedded] embedded run start ... messageChannel=telegram
  1. Telegram outbound/API connectivity is failing 🚨
sendChatAction failed: Network request for 'sendChatAction' failed!
Polling stall detected
getUpdates failed
#

So this is less “bot ignored the message” and more “Gateway/host is having unstable network access to Telegram Bot API”, plus you’re on the buggy 2026.4.24 plugin-runtime-deps window.

Do these in order:

openclaw update
openclaw doctor --fix
openclaw gateway restart
openclaw channels status --probe

Then test Telegram again.

If it still fails, check whether this machine can reach Telegram reliably. From the same Windows host:

# 
curl.exe https://api.telegram.org

If you need a proxy, configure Telegram’s proxy in OpenClaw config, e.g. JSON5:

{
  channels: {
    telegram: {
      proxy: "socks5://user:password@proxy-host:1080",
    },
  },
}

Also paste the log after the embedded run start line — we need to see whether the MiniMax model call finishes and then delivery fails, or whether the model call itself hangs.