agents couldnt get a response | Friends of the Crustacean 🦞🤝 | Page 1

spare cloud Apr 19, 2026, 1:31 AM

#

Goal / Expected Behavior:
I am trying to get the OpenClaw Gateway running as a stable Windows service on version 2026.4.15. I want to reconnect my Telegram bot, which was working on version .14 before the update and a subsequent hard reset.

What happened instead:
The Gateway service crashes immediately upon starting. Running openclaw status shows "Runtime: stopped (Result=1)" and states the service likely exited immediately. When trying to fix the config, I keep hitting "Config validation failed: Unrecognized key" errors for keys like allowInsecure and credentials, which seem to have changed in the latest patch. My Telegram bot is stuck on "⚠️ Agent couldn't generate a response."

What I’ve tried:

Performed a openclaw reset --scope full.

Updated from 2026.4.14 to 2026.4.15.

Ran openclaw doctor --fix (which confirms the service is loaded but not running).

Attempted to manually set gateway.bind to 127.0.0.1, but it was rejected for not using the loopback keyword.

Tried running openclaw gateway --verbose, but the background service still fails to stay alive.

Environment:

OS: Windows 10 (Build 26200)

Version: OpenClaw 2026.4.15 (041266a)

Location: Petaling Jaya, Malaysia (Potential npm/registry timeout issues during doctor runs).

Relevant Logs:

Plaintext
Gateway Status: Reachable: no (1006)
Service Status: stopped (state Ready, last run 1, Result=1)
Error: Config validation failed: gateway.auth: Unrecognized key: "allowInsecure"
Log Snippet: "security audit: device access upgrade required ... scope-upgrade failed"

sonic pagodaBOT Apr 19, 2026, 1:31 AM

#

green slateBOT Apr 19, 2026, 1:34 AM

#

Yeah, that message is annoyingly generic. It usually means Telegram reached the agent, but the model run failed or returned an empty/incomplete turn, so I would check model auth + logs before redoing Telegram again.

Also, openclaw status showing 0 active sessions is not the main signal here.

Please paste these, from the gateway host:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw models status

Then keep this running:

#

openclaw logs --follow

Send one test Telegram message, then paste the log lines around that attempt.

Two common causes after a restart:

API key not actually loaded by the gateway service
If you re-entered the key in your shell, but OpenClaw runs via systemd/launchd, the service may not see it. Put it in ~/.openclaw/.env or enable env.shellEnv.enabled: true, then restart the gateway.
Telegram is connected, but auth/pairing/policy is blocking
For DMs, also check:
```
openclaw pairing list telegram
```

#

If this is a group chat, also check requireMention and Telegram privacy mode.

Docs:

If you paste the version + those outputs, I can help narrow it down fast.

spare cloud Apr 19, 2026, 1:44 AM

#

01:43:48+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=a3e7deaf-65b2-4395-90e5-110e8933ee7c sessionId=7fc92cbc-892e-448b-886f-9b1bca3b020f stopReason=stop payloads=0 — surfacing error to user
01:43:49+00:00 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=8270709677 message=663

this is the log line after i send a test message

green slateBOT Apr 19, 2026, 1:46 AM

#

Nice, this narrows it down a lot.

I think you have 2 separate issues:

The service is crashing on invalid config
Telegram is fine, but the agent/model run is returning an empty turn

Your test log proves #2:

telegram sendMessage ok = Telegram transport is working
incomplete turn detected ... stopReason=stop payloads=0 = the model stopped without producing a visible reply

1) Fix the service crash first

On 2026.4.15, these are the important bits:

gateway.bind must be a mode, not 127.0.0.1

#

use loopback
gateway.auth.allowInsecure is not a valid key
- if you meant localhost HTTP Control UI compatibility, the current key is gateway.controlUi.allowInsecureAuth
if you have a nested credentials object under gateway auth, that is also stale
- use gateway.auth.mode + gateway.auth.token or gateway.auth.password

I’d clean it up like this:

openclaw config unset gateway.auth.allowInsecure
openclaw config set gateway.mode local
openclaw config set gateway.bind loopback
openclaw config set gateway.auth.mode token
openclaw doctor --generate-gateway-token
openclaw config validate

#

If config validate still complains about credentials, paste the full path of that error. credentials by itself is too ambiguous, but gateway.auth.credentials would definitely be wrong on current schema.

If the service still dies after validation passes, run:

openclaw gateway status --deep

That helps catch service config vs CLI config mismatch, which is a known cause of “service loaded, runtime stopped”.

2) The Telegram bot issue is not Telegram anymore

That payloads=0 line means the run reached the agent, then the model returned nothing useful.

Next checks:

#

openclaw models status
openclaw logs --follow

Then send one Telegram test message and grab the log lines just before the incomplete turn detected warning.

A very common cause after reset/update is that the gateway service cannot see your API key, even if your shell can. For daemon/service setups, put the key in:

~/.openclaw/.env

then restart the gateway.

3) About the `scope-upgrade failed` line

#

That is probably a device pairing / scope upgrade issue, separate from the empty Telegram reply.

If you still see 1008 / pairing-required style errors, check:

openclaw devices list

If there is a pending request, approve it with:

openclaw devices approve <requestId>

Recommended stable baseline

For a local Windows service, I’d keep it simple:

#

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: {
      mode: "token",
    },
    controlUi: {
      enabled: true,
    },
  },
}

Docs:

https://docs.openclaw.ai/gateway/configuration

#

If you paste the output of openclaw config validate and openclaw models status, I can probably pinpoint the remaining blocker pretty quickly.

spare cloud Apr 19, 2026, 1:53 AM

#

output for config validate

Config valid: ~.openclaw\openclaw.json

output for openclaw models status

🦞 OpenClaw 2026.4.15 (041266a) — I'm the assistant your terminal demanded, not the one your sleep schedule requested.

Config : ~.openclaw\openclaw.json
Agent dir : ~.openclaw\agents\main\agent
Default : openrouter/deepseek/deepseek-v3.2
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : OpenRouter -> openrouter/auto
Configured models (2): openrouter/auto, openrouter/deepseek/deepseek-v3.2

Auth overview
Auth store : ~.openclaw\agents\main\agent\auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

openrouter effective=profiles:~.openclaw\agents\main\agent\auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...60dc67da

OAuth/token status

this is the result after running openclaw models status and send one test message

gateway connect failed: Error: gateway closed (1000):
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\limpr.openclaw\openclaw.json
Bind: loopback
Hint: run openclaw doctor.

green slateBOT Apr 19, 2026, 1:57 AM

#

Thanks, this helps. I think the diagnosis has shifted a bit.

Right now, your config and model auth look basically fine:

openclaw config validate = valid
openclaw models status = OpenRouter auth is present

So the immediate blocker is not Telegram and probably not provider auth. It is that the local Gateway process is not staying up on Windows.

A few important clarifications for 2026.4.15:

gateway.bind: "loopback" is correct
gateway.auth.allowInsecure is not a current key
gateway.auth.credentials is not a current key
current gateway auth is gateway.auth.mode plus token or password
gateway.controlUi.allowInsecureAuth is a Control UI localhost compatibility toggle, not a general gateway.auth setting

#

Docs:

So I would do this next, in this order, on the Windows gateway host:

openclaw gateway run --verbose

That is the key one. openclaw gateway run is the foreground path, and it should print the real startup error instead of just Result=1.

Then, in another PowerShell window:

#

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
openclaw gateway status --json

If openclaw gateway run --verbose stays up fine, then the problem is likely the Scheduled Task install/action, not the Gateway itself. In that case I’d repair the supervisor:

openclaw gateway uninstall
openclaw gateway install
openclaw gateway status --json

Also, the scope-upgrade failed bit looks like a separate device/pairing scope issue, not the reason ws://127.0.0.1:18789 is closed. I’d ignore that until the Gateway is actually listening again.

Bluntly, native Windows is still a rougher path. The docs currently recommend WSL2 for the most stable setup. If you want, I can help with native Windows first, but if you want the fastest path back to a stable Telegram bot, I’d seriously consider WSL2.

#

If you paste the first 20 to 50 lines from openclaw gateway run --verbose, I can probably tell you exactly why it’s exiting.

spare cloud Apr 19, 2026, 1:59 AM

#

09:58:13 [gateway] loading configuration…
09:58:13 [gateway] resolving authentication…
09:58:13 [gateway] starting...
09:58:18 Gateway failed to start: gateway already running (pid 48448); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
09:58:18 Port 18789 is already in use.
09:58:18 - pid 48448: "C:\Program Files\nodejs\node.exe" C:\Users\limpr\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
09:58:18 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
09:58:18 Gateway service appears registered. Stop it first.
09:58:18 Tip: openclaw gateway stop
09:58:18 Or: schtasks /End /TN "OpenClaw Gateway"

this is what i got after runnin gateway run --verbose, no 20 to 50 lines so i didnt run the rest of the steps

green slateBOT Apr 19, 2026, 2:00 AM

#

Ah, this is actually useful. Your foreground run is not showing a bad config now. It is showing gateway contention.

The important lines are:

gateway already running (pid 48448)
Port 18789 is already in use
that PID is already an OpenClaw gateway process:
...openclaw\\dist\\index.js gateway --port 18789

So the next move is not more config edits. Also, that old gateway.auth.allowInsecure error is probably from the earlier broken config attempt. Your current config validates, so I’d stop touching gateway.auth for the moment.

What to do next

Please run these, in order:

#

openclaw gateway stop
openclaw gateway status --json
schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
openclaw gateway start
openclaw gateway status --json

If openclaw gateway stop says it stopped, but gateway status --json still shows weirdness, paste that output too.

Why this matters

Right now there are 2 likely possibilities:

The Scheduled Task/supervisor is already launching the gateway, and your manual gateway run is just colliding with it.
The supervised gateway is stuck in a bad start/stop loop, so the port is briefly occupied but RPC is not healthy.

#

That is why earlier you saw both:

port already in use
and also Gateway not reachable

Also, ignore this for now

scope-upgrade failed is a separate pairing/scope thing
it is not the reason port 18789 is contended

Once the gateway is actually healthy again, then we can retest Telegram. If Telegram still says ⚠️ Agent couldn't generate a response., we’ll debug that second.

Paste the outputs from the 5 commands above and I’ll narrow it down fast.

spare cloud Apr 19, 2026, 2:07 AM

#

sdf

#

i cant paste the output cause there is more than 2000 words

green slateBOT Apr 19, 2026, 2:07 AM

#

Looks like that may have been an accidental send 🙂

When you can, please paste these outputs:

openclaw gateway stop
openclaw gateway status --json
schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
openclaw gateway start
openclaw gateway status --json

If one of them fails, just paste the failing one first. That should tell us whether this is a stuck supervisor, a bad task action, or a restart loop.

spare cloud Apr 19, 2026, 2:08 AM

#

{
"logFile": "\tmp\openclaw\openclaw-2026-04-19.log",
"service": {
"label": "Scheduled Task",
"loaded": true,
"loadedText": "registered",
"notLoadedText": "missing",
"command": {
"programArguments": [
"C:\Program Files\nodejs\node.exe",
"C:\Users\limpr\AppData\Roaming\npm\node_modules\openclaw\dist\index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_GATEWAY_PORT": "18789"
},
"sourcePath": "C:\Users\limpr\.openclaw\gateway.cmd"
},
"runtime": {
"status": "stopped",
"state": "Ready",
"lastRunTime": "19/04/2026 09:22:05",
"lastRunResult": "267014",
"detail": "Task Last Run Result=267014; treating as not running."
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "C:\Users\limpr\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
},
"daemon": {
"path": "C:\Users\limpr\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
}
},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "free",
"listeners": [],
"hints": []
},
"rpc": {
"ok": false,
"error": "gateway closed (1006): ",
"url": "ws://127.0.0.1:18789"
},
"health": {
"healthy": false,
"staleGatewayPids": []
},
"extraServices": []
}

this is the output for /v /FO LIST

green slateBOT Apr 19, 2026, 2:08 AM

#

Yep, Discord’s 2000-char limit is the annoying part here 😅

Easiest path, save the outputs to files and attach the files here:

openclaw gateway status --json *> gateway-status.json
schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST *> openclaw-task.txt

Then drag gateway-status.json and openclaw-task.txt into the thread.

If you see any token/password in there, redact just that part before uploading.

If attaching files is annoying, then paste only these bits from openclaw-task.txt:

Task To Run
Status

#

Last Run Result

Those 3 lines are probably enough to tell whether the Windows task is pointing at a bad command or crash-looping.

#

Nice, this narrows it down a lot.

What this shows:

the task is installed correctly
it points at a real OpenClaw entrypoint:
C:\Users\limpr\AppData\Roaming\npm\node_modules\openclaw\dist\index.js
both CLI and daemon are using the same valid config
port 18789 is currently free
so the remaining problem is the actual gateway startup, not the task registration

Also, allowInsecureAuth: true is not the thing crashing this.

Next step

Now that the port is free, please run this again:

#

openclaw gateway run --verbose

Earlier it only showed a port collision.
Now it should show the real startup error.

If the output is too long, do this and attach the file:

openclaw gateway run --verbose *> gateway-run.txt

Then drag gateway-run.txt into the thread.

If you really can’t attach files, paste just the last 30 lines.

#

At this point, I think we’re one real error message away from the actual cause.

#

I think the .txt attachment didn’t come through, I only see the pasted JSON.

That JSON is still helpful though. It says:

task registration looks sane
config is valid
port 18789 is currently free
so we still need the actual foreground startup error

Please do this exact flow now:

openclaw gateway stop
openclaw gateway run --verbose *> gateway-run.txt

Then attach gateway-run.txt to the thread.

#

What you pasted so far is basically the status snapshot, not the crash log. The crash log is the missing piece.

If Discord keeps eating the attachment, paste just the last 30 lines from gateway-run.txt.

spare cloud Apr 19, 2026, 2:16 AM

#

10:12:55 [hooks:loader] Registered hook: command-logger -> command
10:12:55 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
10:12:55 [hooks] loaded 4 internal hook handlers
10:13:07 [bonjour] watchdog detected non-announced service; attempting re-advertise (gateway fqdn=limmmmm (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
10:13:09 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
10:13:10 [plugins] embedded acpx runtime backend registered (cwd: C:\Users\limpr.openclaw\workspace)
10:13:10 (node:32328) [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.
(Use node --trace-deprecation ... to show where the warning was created)
10:13:10 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
10:13:11 Registered plugin command: /pair (plugin: device-pair)
10:13:12 Registered plugin command: /dreaming (plugin: memory-core)
10:13:12 Registered plugin command: /phone (plugin: phone-control)
10:13:12 Registered plugin command: /voice (plugin: talk-voice)
10:13:12 [plugins] hook runner initialized with 1 registered hooks
10:13:12 [heartbeat] started
10:13:12 [hooks/boot-md] boot-md skipped for agent startup run
10:13:12 [plugins] embedded acpx runtime backend ready
10:13:13 [telegram] [default] starting provider
10:13:13 [telegram] autoSelectFamily=true (default-node22)
10:13:13 [telegram] dnsResultOrder=ipv4first (default-node22)
10:13:13 [routing] resolveAgentRoute: channel=telegram accountId=default peer=none guildId=none teamId=none bindings=0
10:13:14 [skills] Sanitized skill command name "node-connect" to "/node_connect".
10:13:14 [skills] Sanitized skill command name "skill-creator" to "/skill_creator".
10:13:14 [skills] Sanitized skill command name "taskflow-inbox-triage" to "/taskflow_inbox_triage".

green slateBOT Apr 19, 2026, 2:16 AM

#

This is actually good news.

Those lines do not show a crash. They look like a pretty normal startup:

heartbeat started
browser server listening
plugins loaded
Telegram provider starting

Also, these two lines are probably not the root cause:

pricing bootstrap failed: TimeoutError...
DEP0190 DeprecationWarning...

They’re noisy, but neither looks like the gateway-killer here.

One key question

#

When you ran openclaw gateway run --verbose, did it:

stay running, or
exit/close after these lines?

If it stayed running

Keep that terminal open and send a Telegram test message right now.

If Telegram works while the foreground gateway is open, then I think the real problem is just the Windows Scheduled Task/service path, not the gateway itself.

In that case, next repair step would be:

openclaw gateway uninstall
openclaw gateway install

#

openclaw gateway status --json

If it exited

Then we still need the last lines after the exit, because the actual failure is happening later than what you pasted.

So, short version: this log looks healthy so far.
The next thing I need from you is just: did the process stay alive or did it exit?

spare cloud Apr 19, 2026, 2:19 AM

#

the process just stop didnt exit so it means its alive ?

green slateBOT Apr 19, 2026, 2:19 AM

#

Yep, if it didn’t return to the prompt and is just sitting there, that usually means the gateway is still running.

That is normal for a server process. It can look like it “stopped” when it really just has nothing else to print.

Do this next

Keep that terminal open, then from Telegram send a test message to your bot.

If Telegram works now

Then we’ve basically proven:

the gateway itself is fine
the broken part is the Windows Scheduled Task/service startup

At that point I’d repair the service with:

#

openclaw gateway uninstall
openclaw gateway install
openclaw gateway status --json

If Telegram still says `Agent couldn't generate a response`

Then the gateway is alive, but the agent/model run is failing. In that case, while the foreground gateway is still open, send one Telegram test and paste the new log lines that appear right after the test.

So yes, I think this is progress.
First check is simply: does Telegram work while openclaw gateway run --verbose is kept open?

spare cloud Apr 19, 2026, 2:20 AM

#

yes it works but still agent couldnt generate a response

green slateBOT Apr 19, 2026, 2:21 AM

#

Perfect, that splits it cleanly.

You have 2 separate issues now:

Gateway/service issue on native Windows
- because the foreground gateway works, but the Scheduled Task does not
Model/agent issue
- Telegram transport works, but the model is returning an empty/incomplete turn, which becomes Agent couldn't generate a response

Since your current default is openrouter/deepseek/deepseek-v3.2, the fastest next test is to switch temporarily to your already-configured openrouter/auto.

Try this

Stop the foreground gateway first, then run:

#

openclaw config set agents.defaults.model.primary "openrouter/auto"
openclaw gateway run --verbose

Then send a Telegram test again.

What this tells us

If Telegram starts replying normally, then the problem is very likely the current deepseek-v3.2 path returning empty turns.
If it still says Agent couldn't generate a response, then while that foreground gateway is open, send one test and paste the new lines that appear right after the test.

So I’d do the model swap first. It’s the fastest way to confirm whether this is a provider/model empty-response bug versus a deeper agent runtime issue.

spare cloud Apr 19, 2026, 2:30 AM

#

still the same answer after changing to the openrouter/auto model

green slateBOT Apr 19, 2026, 2:31 AM

#

Got it. Since openrouter/auto gives the same result, this is probably not just that one model ID.

At this point I’d isolate provider/model vs agent runtime.

Run this exact test

openclaw infer model run --model openrouter/auto --prompt "Reply with exactly OPENCLAW-MODEL-OK" --json

Why

If that returns a normal reply, then OpenRouter/model auth is fine, and the bug is in the agent/session/runtime layer
If that errors or returns empty, then the issue is still in the model/provider path

If that command works, I’d next want the log lines right after a Telegram test while the foreground gateway is running.

#

If it fails, paste the output from that command first. That should narrow this down a lot faster than guessing.

spare cloud Apr 19, 2026, 2:32 AM

#

10:32:40 [agent/embedded] incomplete turn detected: runId=6e169978-be84-47c2-8958-0dcd1b11bebf sessionId=6e169978-be84-47c2-8958-0dcd1b11bebf stopReason=stop payloads=0 — surfacing error to user
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openrouter",
"model": "openrouter/auto",
"attempts": [],
"outputs": [
{
"text": "⚠️ Agent couldn't generate a response. Please try again.",
"mediaUrl": null
}
]
}

this the output

green slateBOT Apr 19, 2026, 2:33 AM

#

That output is actually very helpful.

It confirms the exact failure mode:

incomplete turn detected
stopReason=stop
payloads=0

So the run is ending without any visible assistant text.

One important nuance: openclaw infer model run reuses the normal agent runtime, so it is reproducing the same bug, not isolating the provider by itself.

Next test, probe OpenRouter directly

Please run:

#

openclaw models status --probe --probe-provider openrouter

Why this is the right next step

If the probe says ok, then OpenRouter auth/provider access is fine, and the problem is in the agent runtime/session layer
If the probe fails, then the issue is still in the provider/auth/model path

So this next command is the cleanest split.

Paste that output, and I think we’ll know which side of the system is actually broken.

spare cloud Apr 19, 2026, 2:35 AM

#

this one right

green slateBOT Apr 19, 2026, 2:36 AM

#

Yep, that’s the right one.

That result is important:

OpenRouter auth is good
the provider probe works
so this is not Telegram transport
and it’s not basic OpenRouter auth/model access

So the broken part is now narrowed to the agent runtime/session layer.

Next test

Please run the native Windows smoke test from the docs:

#

openclaw agent --local --agent main --thinking low -m "Reply with exactly WINDOWS-HATCH-OK."

How to read it

If that prints WINDOWS-HATCH-OK, then the agent runtime is okay locally, and the issue is more specific to the channel/session flow
If that also fails or gives the same incomplete-turn behavior, then I think you’ve found a native Windows agent-runtime regression on 2026.4.15

At that point, the picture would be pretty clear:

provider probe = ok
foreground gateway = works
Telegram transport = works
agent turn = broken

If the smoke test fails too, I’d honestly treat that as a bug and point you to file it here with the outputs you already gathered: https://github.com/openclaw/openclaw/issues

#

Paste the result of that one command first, though. That’s the cleanest final split.

spare cloud Apr 19, 2026, 2:47 AM

#

there is nothing happening in my powershell, just stopped blank screen

green slateBOT Apr 19, 2026, 2:47 AM

#

Yep, that’s not normal.

That smoke test should either:

print the reply, or
fail with an error

It should not just sit on a blank PowerShell screen.

At this point, I think you’ve isolated this pretty well:

openclaw config validate = valid
openclaw models status --probe --probe-provider openrouter = ok
foreground openclaw gateway run --verbose = gateway stays alive
Telegram transport = works
agent turns = empty/incomplete (payloads=0)
local agent smoke test = hangs blank

#

Scheduled Task/service = still flaky on native Windows

So bluntly, I think this is now a native Windows regression/bug on 2026.4.15, not a bad Telegram config and not bad OpenRouter auth.

What I’d do next

1. File a GitHub issue

Please open one here:

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

Include these exact points:

OpenClaw 2026.4.15 (041266a)
Windows 10 (Build 26200)
openclaw config validate passes
openclaw models status --probe --probe-provider openrouter returns ok

#

foreground gateway stays running
Telegram reaches the bot, but replies are ⚠️ Agent couldn't generate a response.
logs show:
- incomplete turn detected ... stopReason=stop payloads=0
openclaw agent --local --agent main --thinking low -m "Reply with exactly WINDOWS-HATCH-OK."
hangs on a blank screen
Scheduled Task/service does not stay healthy on native Windows

2. Use WSL2 as the practical workaround

The Windows docs already call WSL2 the recommended/stable path:

https://docs.openclaw.ai/platforms/windows

I’d honestly stop burning time on native Windows for this one and move the gateway into WSL2 if you need it working today.

Small note

#

The earlier gateway.auth.allowInsecure / credentials errors look like a separate old-config red herring now. Your current config validates, so I would not keep chasing that part.

If you want, I can help you write a tight GitHub issue body from everything you already collected, or help you move this exact setup into WSL2.

spare cloud Apr 19, 2026, 2:48 AM

#

is it possible that i go back one version on openclaw and it could work ?

green slateBOT Apr 19, 2026, 2:49 AM

#

Yes, absolutely. And in your case, I think it’s a reasonable temporary workaround since 2026.4.14 reportedly worked before.

The docs support rollback by pinning a version:

https://docs.openclaw.ai/install/updating

If you want to try `.14`

On a normal Windows npm/global install:

openclaw gateway stop
npm i -g openclaw@2026.4.14
openclaw doctor
openclaw gateway restart
openclaw --version

#

You want that last line to show 2026.4.14.

My read

Given everything you tested, if .14 works again, that is strong evidence of a regression in .15 on native Windows.

If rollback fixes it, I’d still file a GitHub issue with the exact comparison:

2026.4.14 works
2026.4.15 breaks on native Windows
provider probe is ok
foreground gateway lives
agent turns hang / return incomplete-turn payloads=0

Issue tracker:
https://github.com/openclaw/openclaw/issues

#

If you want, I can help you write a short issue body after you test the rollback.

spare cloud Apr 19, 2026, 2:55 AM

#

Config was last written by a newer OpenClaw (2026.4.15); current version is 2026.4.14.

green slateBOT Apr 19, 2026, 2:56 AM

#

That message is just a warning, not necessarily a blocker.

I checked the current source, and that exact line is emitted as a warning when an older OpenClaw sees config metadata stamped by a newer version.

So if you already rolled back to 2026.4.14, this part is expected:

.15 last touched the config
.14 is warning you about that

In practice

If commands still run after that line, keep going. I’d test .14 directly now:

openclaw --version
openclaw doctor

#

openclaw gateway run --verbose

Then send a Telegram test.

What I’d expect

If .14 now replies normally, that’s very strong evidence .15 introduced the regression on native Windows
If .14 still has the same hang/incomplete-turn behavior, then rollback didn’t actually dodge the root problem

So, short answer: yes, rollback is still possible, and that specific message alone does not mean it failed.

If you want, paste what happens after that warning on .14, and I’ll help you judge whether the rollback actually worked.

spare cloud Apr 19, 2026, 3:00 AM

#

ok i think it still have the same error, lets report a bug to github write me a detail of what happened

green slateBOT Apr 19, 2026, 3:01 AM

#

Yep, here’s a solid GitHub issue draft you can paste.

Issue link: https://github.com/openclaw/openclaw/issues

Title

Native Windows regression on 2026.4.15: Scheduled Task Gateway unhealthy, agent turns hang / return incomplete-turn payloads=0, Telegram replies Agent couldn't generate a response

Body

Summary

I’m seeing a native Windows issue after updating from 2026.4.14 to 2026.4.15.

On 2026.4.15, the Gateway Scheduled Task does not stay healthy, and even when I run the Gateway manually in the foreground, agent turns either hang or end as an incomplete turn with no payloads. Telegram transport itself works, but replies come back as:

#

⚠️ Agent couldn't generate a response. Please try again.

This appears to be beyond simple config/auth issues, because provider auth probes succeed and Telegram can reach the Gateway.

Environment

OS: Windows 10 (Build 26200)
OpenClaw version: 2026.4.15 (041266a)
Install type: native Windows global install
Provider: OpenRouter
Default model tested:
- openrouter/deepseek/deepseek-v3.2
- openrouter/auto
Location: Petaling Jaya, Malaysia

Expected behavior

#

Gateway Scheduled Task should stay healthy on native Windows
Telegram bot should respond normally
Local agent smoke tests should either return output or fail with a concrete error, not hang or return incomplete-turn fallback text

Actual behavior

openclaw gateway status / status --json reports Scheduled Task registered but not running healthy
Telegram transport works, but replies are:
- ⚠️ Agent couldn't generate a response. Please try again.
Foreground Gateway can stay alive, but agent turns still fail
Local agent smoke test hangs on a blank PowerShell screen
Embedded runner logs show incomplete turns with no payloads

Things I tested

Config / auth

#

openclaw config validate passed
OpenRouter auth probe succeeded:

Auth probes
+----------------------------+------------------------------+------------+
| Model                      | Profile                      | Status     |
+----------------------------+------------------------------+------------+
| openrouter/openrouter/auto | openrouter:default (api_key) | ok · 15.2s |

So this does not look like missing OpenRouter auth.

Gateway / service

The Windows Scheduled Task is registered and points to a real OpenClaw entrypoint:

#

{
  "service": {
    "label": "Scheduled Task",
    "loaded": true,
    "command": {
      "programArguments": [
        "C:\\Program Files\\nodejs\\node.exe",
        "C:\\Users\\limpr\\AppData\\Roaming\\npm\\node_modules\\openclaw\\dist\\index.js",
        "gateway",
        "--port",
        "18789"
      ],
      "environment": {
        "OPENCLAW_GATEWAY_PORT": "18789"
      },

#

      "sourcePath": "C:\\Users\\limpr\\.openclaw\\gateway.cmd"
    },
    "runtime": {
      "status": "stopped",
      "state": "Ready",
      "lastRunResult": "267014"
    }
  },
  "config": {
    "cli": {
      "path": "C:\\Users\\limpr\\.openclaw\\openclaw.json",
      "exists": true,
      "valid": true
    },
    "daemon": {

#

      "path": "C:\\Users\\limpr\\.openclaw\\openclaw.json",
      "exists": true,
      "valid": true
    }
  },
  "port": {
    "port": 18789,
    "status": "free"
  },
  "rpc": {
    "ok": false,
    "error": "gateway closed (1006): ",
    "url": "ws://127.0.0.1:18789"
  }
}

#

Foreground Gateway

When I run:

openclaw gateway run --verbose

the Gateway can stay alive in the foreground. Startup logs look normal, including Telegram provider startup. That suggests the gateway can run, but agent turns are still broken.

Telegram

Telegram reaches the Gateway, but replies still fail with:

⚠️ Agent couldn't generate a response. Please try again.

Embedded runner log

#

Foreground logs show:

[agent/embedded] incomplete turn detected: runId=... sessionId=... stopReason=stop payloads=0 — surfacing error to user

Direct model run via infer

I also tested:

openclaw infer model run --model openrouter/auto --prompt "Reply with exactly OPENCLAW-MODEL-OK" --json

and got:

#

{
  "ok": true,
  "capability": "model.run",
  "transport": "local",
  "provider": "openrouter",
  "model": "openrouter/auto",
  "attempts": [],
  "outputs": [
    {
      "text": "⚠️ Agent couldn't generate a response. Please try again.",
      "mediaUrl": null
    }
  ]
}

#

with the same incomplete-turn log:

[agent/embedded] incomplete turn detected ... stopReason=stop payloads=0

Local agent smoke test

I also ran:

openclaw agent --local --agent main --thinking low -m "Reply with exactly WINDOWS-HATCH-OK."

and PowerShell just sat on a blank screen. It did not print output or fail with a clear error.

Additional notes

#

I initially saw config validation issues around old keys like gateway.auth.allowInsecure / credentials, but after cleanup the config validates, so those now look like a red herring rather than the root cause
I also tried changing from openrouter/deepseek/deepseek-v3.2 to openrouter/auto, but the same incomplete-turn behavior remained
I attempted rolling back to 2026.4.14, but the issue still appeared to persist after that point

My current suspicion

This looks like a native Windows runtime/session regression in the embedded agent path, because:

config validates
provider auth probe is ok
Telegram transport works
foreground gateway can run
but agent turns either hang or terminate as incomplete turns with payloads=0

If you want, I can also turn this into a shorter maintainer-friendly version.

spare cloud Apr 26, 2026, 11:56 AM

#

Fixed on main in 54f4c45.

What I verified:

Reproduced the reported local openclaw infer model run --model openrouter/auto --prompt "Reply with exactly OPENCLAW-MODEL-OK" --json path returning ok: true with outputs: [] after the model produced NO_REPLY.
Found two root causes: explicit OpenRouter dynamic model refs still forced full catalog / models.json discovery, and one-shot model probes inherited the chat-agent silent-reply prompt policy.
Updated local/gateway model.run probes to use no-tools plain prompt mode, and changed explicit dynamic model resolution to avoid unrelated provider catalog discovery.
Re-ran the exact smoke command from source with a clean temp config/state; it now returns outputs[0].text = "OPENCLAW-MODEL-OK".
Added regression coverage and ran pnpm check:changed successfully.
Closing as completed. Please reopen or create a new issue if the latest main build still hangs or returns empty output with fresh logs/config details.

i got this response from github what is my step to fix it

#

hi

#

@green slate

spare cloud Apr 26, 2026, 12:24 PM

#

Fixed on main in 54f4c45.

What I verified:

Reproduced the reported local openclaw infer model run --model openrouter/auto --prompt "Reply with exactly OPENCLAW-MODEL-OK" --json path returning ok: true with outputs: [] after the model produced NO_REPLY.
Found two root causes: explicit OpenRouter dynamic model refs still forced full catalog / models.json discovery, and one-shot model probes inherited the chat-agent silent-reply prompt policy.
Updated local/gateway model.run probes to use no-tools plain prompt mode, and changed explicit dynamic model resolution to avoid unrelated provider catalog discovery.
Re-ran the exact smoke command from source with a clean temp config/state; it now returns outputs[0].text = "OPENCLAW-MODEL-OK".
Added regression coverage and ran pnpm check:changed successfully.
Closing as completed. Please reopen or create a new issue if the latest main build still hangs or returns empty output with fresh logs/config details.

#agents couldnt get a response

1) Fix the service crash first

2) The Telegram bot issue is not Telegram anymore

3) About the scope-upgrade failed line

Recommended stable baseline

What to do next

Why this matters

Also, ignore this for now

Next step

One key question

If it stayed running

If it exited

Do this next

If Telegram works now

If Telegram still says Agent couldn't generate a response

Try this

What this tells us

Run this exact test

Why

Next test, probe OpenRouter directly

Why this is the right next step

Next test

How to read it

What I’d do next

1. File a GitHub issue

2. Use WSL2 as the practical workaround

Small note

If you want to try .14

My read

In practice

What I’d expect

Title

Body

Summary

Environment

Expected behavior

Actual behavior

Things I tested

Config / auth

Gateway / service

Foreground Gateway

Telegram

Embedded runner log

Direct model run via infer

Local agent smoke test

Additional notes

My current suspicion

3) About the `scope-upgrade failed` line

If Telegram still says `Agent couldn't generate a response`

If you want to try `.14`