Agent Does not Response any Chat | Friends of the Crustacean 🦞🤝 | Page 1

shy bone Apr 18, 2026, 5:13 AM

#

Im using the latest of openclaw, im installing by docs on the website. After all i start a chat. But the agent does not return output or response

fervent hamletBOT Apr 18, 2026, 5:13 AM

#

magic inletBOT Apr 18, 2026, 5:13 AM

#

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

jade crowBOT Apr 18, 2026, 5:14 AM

#

That usually means one of 3 things: the agent never ran, the model is not usable, or Discord dropped the message because of policy.

First, please paste these:

openclaw --version
openclaw status --all
openclaw models status
openclaw gateway status

Then keep this running:

openclaw logs --follow

#

Send one test message, and paste the log lines that appear right after.

A couple quick checks too:

If you’re testing in a Discord server channel, try @mentioning the bot. Guild messages are mention-gated by default.
If you want replies without mentions, set channels.discord.guilds.<YOUR_SERVER_ID>.requireMention = false
If you’re testing in DMs, check whether pairing is still pending:
```
openclaw pairing list discord
```

Docs:

FAQ: https://docs.openclaw.ai/help/faq
Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting
Discord channel setup: https://docs.openclaw.ai/channels/discord

Paste the command output and I’ll help narrow it down fast.

shy bone Apr 18, 2026, 6:12 AM

#

openclaw models status ok 12s 01:09:25 PM

🦞 OpenClaw 2026.4.15 (041266a) — I've read more man pages than any human should—so you don't have to.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openrouter/openrouter/auto (from openrouter/auto)
Fallbacks (1) : openrouter/nvidia/nemotron-3-super-120b-a12b:free
Image model : -
Image fallbacks (0): -
Aliases (1) : OpenRouter -> openrouter/auto
Configured models (2): openrouter/auto, openrouter/nvidia/nemotron-3-super-120b-a12b:free

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

openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth
openrouter effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | openrouter:default=sk-or-v1...cdf337d2

OAuth/token status
[openai-codex] Token refresh failed: 401 {
"error": {
"message": "Your refresh token has already been used to generate a new access token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "refresh_token_reused"
}
}
[openai-codex] Token refresh failed: 401 {
"error": {
"message": "Your refresh token has already been used to generate a new access token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "refresh_token_reused"
}
}

openai-codex
- openai-codex:default ok expires in 0m

jade crowBOT Apr 18, 2026, 6:12 AM

#

Nice, this helps.

The openai-codex 401 is real, but it’s probably not the main problem here, because your default model is OpenRouter:

Default: openrouter/auto
OpenRouter API key is present
openai-codex refresh_token_reused just means your Codex OAuth needs re-login if you want to use Codex

So next we need to split this into:

Can the model answer at all?
Or is Discord dropping/routing the message wrong?

Please run these next:

#

openclaw infer model run --model openrouter/auto --prompt "say hi" --json
openclaw status --all
openclaw channels status --probe

And in another terminal:

openclaw logs --follow

Then send one test message to the bot and paste the new log lines.

Also, if you’re testing in a Discord server channel, make sure you @mention the bot first. By default, Discord guild replies are mention-gated unless requireMention: false is set for that guild/channel.

If you want, you can also re-auth Codex later, but I would debug the reply path first:

#

FAQ: https://docs.openclaw.ai/help/faq
Discord docs: https://docs.openclaw.ai/channels/discord
Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

Paste those 3 outputs and the log snippet, and we can narrow it down fast.

shy bone Apr 18, 2026, 6:14 AM

#

error gateway connect failed: GatewayClientRequestError: pairing required
06:14:01+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
gateway connect failed: GatewayClientRequestError: pairing required
06:14:01+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":23,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"79a917a5-9278-4cef-8b4e-80c38ece1bee","host":"127.0.0.1:18789","remoteAddr":"127.0.0.1","remotePort":50954,"localAddr":"127.0.0.1","localPort":18789,"endpoint":"127.0.0.1:50954->127.0.0.1:18789","deviceId":"616e3c07763ee63ea3ab945527be358388cdd028dc841f15cf643906125dba42","requestId":"cee0d815-cbe7-41b8-9c31-99d50214d1f0","reason":"scope-upgrade"} closed before connect conn=c5265010-8b85-4483-93ce-714ecbb611a7 peer=127.0.0.1:50954->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1008 reason=connect failed
06:14:02+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=616e3c07763ee63ea3ab945527be358388cdd028dc841f15cf643906125dba42 ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=d5505ac1-9a20-4619-a9a5-3a3d8ae0987e

jade crowBOT Apr 18, 2026, 6:15 AM

#

Yep, we found it.

This is not the model now, it’s gateway pairing / scope-upgrade.

Your log says the client is trying to upgrade from:

operator.read

to:

operator.admin
operator.approvals
operator.pairing
operator.write
operator.talk.secrets

and the gateway is rejecting it with:

#

GatewayClientRequestError: pairing required
reason: "scope-upgrade"

Fix

Run:

openclaw devices list

Then approve the latest pending request with its exact request ID:

openclaw devices approve <requestId>

#

Important: if it retried a few times, the old request may be stale, so run openclaw devices list right before approving.

After that, reconnect and test again. If needed, restart once:

openclaw gateway restart

If it still fails

Paste:

openclaw devices list
openclaw status

#

Docs:

Devices CLI: https://docs.openclaw.ai/cli/devices
Control UI pairing: https://docs.openclaw.ai/web/control-ui
Troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

You’re close, this one looks like a straight pairing approval issue.

shy bone Apr 18, 2026, 6:21 AM

#

Security audit
Summary: 2 critical · 4 warn · 1 info
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - openrouter/nvidia/nemotron-3-super-120b-a12b:free (120B) @ agents.defaults.model.fallbacks (unsafe; sandbox=off; web=[…
Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
CRITICAL Telegram group commands have no sender allowlist
Telegram group access is enabled but no sender allowlist is configured; this allows any group member to invoke /… commands (including skill commands).
Fix: Approve yourself via pairing (recommended), or set channels.telegram.groupAllowFrom (or per-group groups.<id>.allowFrom).
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Control UI insecure auth toggle enabled
gateway.controlUi.allowInsecureAuth=true does not bypass secure context or device identity checks; only dangerouslyDisableDeviceAuth disables Control UI device…
Fix: Disable it or switch to HTTPS (Tailscale Serve) or localhost.
WARN Insecure or dangerous config flags enabled
Detected 1 enabled flag(s): gateway.controlUi.allowInsecureAuth=true.
Fix: Disable these flags when not actively debugging, or keep deployment scoped to trusted/local-only networks.
WARN Some gateway.nodes.denyCommands entries are ineffective
gateway.nodes.denyCommands uses exact node command-name matching only (for example system.run), not shell-text filtering inside a command payload. - Unknown …

jade crowBOT Apr 18, 2026, 6:21 AM

#

That audit is helpful, but it’s not the thing blocking replies.

The blocker is still the earlier error:

gateway connect failed: pairing required
reason="scope-upgrade"

So the next command we need is still:

openclaw devices list

Then approve the pending request with the exact requestId:

#

openclaw devices approve <requestId>

A small gotcha: openclaw devices approve --latest only previews. You need the real request ID to actually approve it.

About the audit you pasted

Those are worth fixing, but they are separate:

Small model fallback unsafe
Either remove openrouter/nvidia/nemotron-3-super-120b-a12b:free for now, or enable sandboxing + disable web tools for small models.
Telegram group allowlist missing
If you use Telegram groups, set an allowlist. If not, disable Telegram group access.
allowInsecureAuth=true
Best to turn that off unless you’re actively debugging.

#

But first, please paste the output of:

openclaw devices list

That should show the pending pairing request we need to approve.

shy bone Apr 18, 2026, 6:25 AM

#

OpenClaw 2026.4.15 (041266a) — Self-hosted, self-updating, self-aware (just kidding... unless?).

│
◇
Paired (2)
┌────────────────────────────────────────────────────────────────┬────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────┬────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├────────────────────────────────────────────────────────────────┼────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────────┼────────────┤
│ 616e3c07763ee63ea3ab945527be358388cdd028dc841f15cf643906125dba │ operator │ operator.read, operator.admin, operator.write, operator.approvals, operator.pairing, operator.talk. │ operator │ │
│ 42 │ │ secrets │ │ │
│ 29d57b399503c1ba0148215553842191fb3d602f0d014ab9fbc1eb9f07adf3 │ operator │ operator.admin, operator.read, operator.write, operator.approvals, operator.pairing │ operator │ │
│ 44 │ │ │ │ │
└────────────────────────────────────────────────────────────────┴────────────┴─────────────────────────────

jade crowBOT Apr 18, 2026, 6:26 AM

#

Good, that helps a lot.

That device is now already paired with full operator scopes, so the original pairing issue looks approved.

Next step

Run these in order:

openclaw gateway restart
openclaw infer model run --model openrouter/auto --prompt "say hi" --json

What this tells us

If infer model run works, the model path is fine and the problem is the chat surface/client
If it fails, paste that output and we can debug the model side next

#

If you still get `pairing required`

Then the client is probably using a stale cached device token. In that case rotate the affected device token and retry:

openclaw devices rotate --device 616e3c07763ee63ea3ab945527be358388cdd028dc841f15cf643906125dba42 --role operator
openclaw gateway restart

If that still doesn’t clear it, then remove and re-pair that device:

openclaw devices remove 616e3c07763ee63ea3ab945527be358388cdd028dc841f15cf643906125dba42
openclaw devices list
openclaw devices approve <requestId>

#

After that, paste:

output of openclaw infer model run ...
the new error if any
which chat you’re using exactly, Dashboard / CLI / Discord / Telegram

We’re close. Right now this looks like either stale client auth or a chat-surface issue, not a dead gateway.

shy bone Apr 18, 2026, 6:28 AM

#

openclaw infer model run --model ok 15s 01:27:29 PM
error: option '--model <provider/model>' argument missing

jade crowBOT Apr 18, 2026, 6:28 AM

#

Yep, that one just missed the model value.

Run this exact command:

openclaw infer model run --model openrouter/auto --prompt "say hi" --json

Then paste the full output.

If that works, the model is fine and we’ll focus on the chat surface next.

shy bone Apr 18, 2026, 6:30 AM

#

openclaw infer model run --model openrouter/auto --prompt "say hi" --json 1 err 01:27:53 PM
13:30:19 [agent/embedded] incomplete turn detected: runId=d0574d5a-1175-4f56-b407-c281bc610b1b sessionId=d0574d5a-1175-4f56-b407-c281bc610b1b 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
}
]
}

jade crowBOT Apr 18, 2026, 6:31 AM

#

Perfect, that narrows it down.

This means the problem is not Discord/chat routing anymore. The model path itself is failing:

infer model run failed directly
payloads=0
Agent couldn't generate a response

So now we need the gateway logs during the model call.

Please do this next

In terminal 1:

openclaw logs --follow

#

In terminal 2:

openclaw infer model run --model openrouter/auto --prompt "say hi" --json

Then paste the new log lines from terminal 1.

One more useful test

Since openrouter/auto hides the actual route, also try a concrete OpenRouter model:

openclaw models list

Pick one exact openrouter/... model from that list, then run:

#Agent Does not Response any Chat

Fix