I'm getting an approval request error like it is bugging me every time I command my agent to do >>> | Friends of the Crustacean 🦞🤝 | Page 1

past cosmos Apr 13, 2026, 5:37 AM

#

After hitting the update latest updater for openclaw I am getting Approval request every time I command my agent to do something why I am getting this like it is a hell!!

rapid martenBOT Apr 13, 2026, 5:37 AM

#

visual pagodaBOT Apr 13, 2026, 5:37 AM

#

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

rapid martenBOT Apr 13, 2026, 5:37 AM

#

past cosmos Apr 13, 2026, 5:38 AM

#

I'm getting an approval request error help me to fix it like I cannot command my agent to do anything it is just hitting me with approval request but I have done everything inside the node pannel Of open claw wen UI

pliant riverBOT Apr 13, 2026, 5:39 AM

#

Yeah, that’s annoying as hell.

Most likely cause: your exec approval policy got tightened, so the agent now has to ask before host commands.

Please paste these first:

openclaw --version
openclaw exec-policy show
openclaw approvals get

If you want the old no-prompt behavior back on the local gateway machine, quickest reset is:

openclaw exec-policy preset yolo

#

openclaw gateway restart

If you prefer the explicit version instead:

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

Important bit: there are now 2 layers, and the stricter one wins:

tools.exec.* in OpenClaw config
host-local ~/.openclaw/exec-approvals.json

#

So if that host approvals file says ask: "always", you’ll keep getting prompts every time.

Docs:

Paste the 3 command outputs and I’ll tell you exactly which layer is causing it.

#

If you changed it only in the Node panel, that may be the problem.

OpenClaw has two approval layers, and the stricter one wins:

OpenClaw config (tools.exec.*)
host approvals (exec-approvals.json, edited in Control UI → Nodes → Exec approvals)

Also, the UI target matters:

Target = Gateway affects gateway-host exec
Target = Node affects that node only

So if your session is running commands on Gateway, changing the Node target won’t stop the prompts.

Try this exact order:

Control UI → Nodes → Exec approvals

#

set Target = Gateway
- Scope = Defaults
- Security = full
- Ask = off
- Save

If you actually use a node/mac app for exec, repeat the same with Target = your Node
Restart:

openclaw gateway restart

In the chat, either start a fresh session:

/new

#

or reset this session’s exec mode:

/exec host=gateway security=full ask=off

If you want the CLI shortcut instead, this is the fastest local reset:

openclaw exec-policy preset yolo
openclaw gateway restart

If it still keeps prompting, paste these and I’ll pinpoint which layer is stuck:

openclaw --version

#

openclaw exec-policy show
openclaw approvals get --gateway

Docs:

past cosmos Apr 13, 2026, 5:41 AM

#

Like I want to give custom access to my Subagents

pliant riverBOT Apr 13, 2026, 5:42 AM

#

Ah, got it, that’s a different knob.

If you want custom access for subagents, that is not controlled by the Node approvals panel.
That part lives in your config under tools.subagents.tools.

Example:

{
  agents: {
    defaults: {
      subagents: {
        allowAgents: ["*"], // or ["research", "coder"]
        maxSpawnDepth: 1
      }
    }

#

  },
  tools: {
    subagents: {
      tools: {
        allow: ["read", "write", "exec", "process"],
        deny: ["message", "browser"]
      }
    }
  }
}

Important gotchas:

allow makes it allow-only
deny still wins

#

if a tool was denied earlier by global/agent policy, subagent policy cannot re-grant it
giving subagents exec does not bypass host approvals

So there are really 2 separate things:

Can the subagent use the tool at all? → tools.subagents.tools
Will host exec still ask for approval? → Gateway/Node exec approval policy

So if you want subagents to run commands without approval prompts, you need both:

subagents allowed to use exec
actual exec host set to no-prompt (security=full, ask=off) on Gateway or the Node they run on

Also, if you want subagents to spawn other agent profiles, use:

#

{
  agents: {
    defaults: {
      subagents: {
        allowAgents: ["*"] // or specific ids
      }
    }
  }
}

Docs:

If you paste your tools.subagents block plus:

#

openclaw --version
openclaw exec-policy show
openclaw approvals get --gateway

I can tell you the exact config to change.

past cosmos Apr 13, 2026, 5:45 AM

#

Yes I got the output from the terminal but it is impossible because on the web uiI just set the allow list for every agent but here it is not changing I think something is wrong with the webui it is not saving my allow list!!

pliant riverBOT Apr 13, 2026, 5:46 AM

#

I would not call it a Web UI save bug yet. Two super common things look exactly like that:

ask is still always
In that mode, an allowlisted command still prompts every time.
You edited the wrong target
You saved the allowlist on Node, but exec is actually running on Gateway (or the other way around).

Also, one nasty detail: if the agent is using wrappers like bash -lc ..., shell chains, or inline eval, allowlisting the inner command often does not help. In allowlist mode those can still count as misses.

So the rule of thumb is:

if you want careful curated access, use
security=allowlist + ask=on-miss
if you want no prompts at all, use
security=full + ask=off

#

If your goal is “stop asking me every damn time”, I’d stop fighting allowlists and set full/off on the actual exec host.

Please paste the exact terminal output from:

openclaw --version
openclaw approvals get --gateway
openclaw exec-policy show

And if you use a node for exec, also:

openclaw approvals get --node <your-node-name-or-id>

If those outputs show your allowlist is really not persisting after Save, then yeah, that starts looking like a real UI bug, and it should go to GitHub: https://github.com/openclaw/openclaw/issues

#

Docs:

past cosmos Apr 13, 2026, 5:48 AM

#

GatewayRequestError: invalid exec.approvals.set params: at /file/agents/main/allowlist/1: unexpected property 'source'; at /file/agents/main/allowlist/2: unexpected property 'source'; at /file/agents/main/allowlist/3: unexpected property 'source'; at /file/agents/andrew/allowlist/0: unexpected property 'source'; at /file/agents/andrew/allowlist/1: unexpected property 'source'; at /file/agents/andrew/allowlist/2: unexpected property 'source'; at /file/agents/cody/allowlist/0: unexpected property 'source'; at /file/agents/net/allowlist/0: unexpected property 'source'; at /file/agents/net/allowlist/1: unexpected property 'source'; at /file/agents/net/allowlist/2: unexpected property 'source'; at /file/agents/net/allowlist/3: unexpected property 'source'

pliant riverBOT Apr 13, 2026, 5:49 AM

#

Yep, that’s the smoking gun. This looks like a real bug, not you.

What’s happening:

the UI is trying to save allowlist entries that contain a source field
exec.approvals.set currently rejects source
so the save fails, which is why it looks like the Web UI is not persisting

Your error proves it:

unexpected property 'source'

So right now the workaround is:

Open the approvals file on the actual exec host

#

(Gateway host or the Node host you selected in the UI)

~/.openclaw/exec-approvals.json

Remove every source key under:

agents.*.allowlist[*]

Save the file
Restart the gateway (and node too, if that’s where exec runs)

#

openclaw gateway restart

After that, try the UI save again.

So yes, in this case the UI/save path is busted because of schema mismatch.

Please file a bug with:

openclaw --version
that exact error
whether you were saving Gateway or Node approvals

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

If you want, paste a redacted chunk of your exec-approvals.json here and I’ll point out exactly what to delete.

past cosmos Apr 13, 2026, 10:19 AM

#

Like after adding one provider api key I only select one model on that provider but I don't know why opencl fetch out all the models from the provider and the model is to look like this but I do not want this I only want those model in my list those I want to have in my list not every model like the provider api key provide as such by that only key I can configure every model but I do not want every model in my list only some selective model how can I change that

ubuntu@hunter-a1-flex:~$ openclaw models list

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

Model Input Ctx Local Auth Tags
chutes/zai-org/GLM-4.7-TEE - - - - default,configured,missing
chutes/Qwen/Qwen3-32B - - - - fallback#1,configured,missing
chutes/unsloth/Mistral-Nemo-Instruct-2407 - - - - fallback#2,configured,missing
chutes/deepseek-ai/DeepSeek-V3-0324-TEE - - - - fallback#3,configured,missing
chutes/Qwen/Qwen3-235B-A22B-Instruct-25... - - - - fallback#4,configured,missing
chutes/openai/gpt-oss-120b-TEE - - - - fallback#5,configured,missing
chutes/chutesai/Mistral-Small-3.1-24B-I... - - - - fallback#6,configured,missing
chutes/deepseek-ai/DeepSeek-V3.2-TEE - - - - fallback#7,configured,missing
chutes/moonshotai/Kimi-K2.5-TEE - - - - fallback#8,configured,missing
chutes/unsloth/gemma-3-27b-it - - - - fallback#9,configured,missing

pliant riverBOT Apr 13, 2026, 10:20 AM

#

What you pasted is not “all models from the provider”.

Those rows are your configured primary + fallback chain.
The giveaway is the tags:

default
fallback#1
fallback#2
etc.

So if you want only one model in that list, do this:

openclaw models set <provider/model-you-want>
openclaw models fallbacks clear

#

If you also set image fallbacks before, clear those too:

openclaw models image-fallbacks clear

So there are really 2 different goals:

Option 1, recommended

You only want one runtime model selected.

Use:

openclaw models set <provider/model>
openclaw models fallbacks clear

#

Option 2

You want to manually curate the provider catalog itself.

Then define only the models you want under:

models.providers.<provider>.models

And if you want config to fully rewrite the agent models.json, use:

models: {
  mode: "replace"
}

#

Docs:

One more thing: your rows are also tagged missing, which usually means auth/model resolution is still not clean on the gateway host. Check that too:

openclaw models status

If you paste the output of:

openclaw models fallbacks list
openclaw models status

#

I can tell you exactly which config line to remove.

past cosmos Apr 13, 2026, 1:43 PM

#

⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again.

To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.

pliant riverBOT Apr 13, 2026, 1:44 PM

#

That message means the session hit the context window and OpenClaw hard-reset the thread.

So the immediate fix is simple:

retry in the fresh session, or
run /compact earlier on long threads
use /new if the thread is already bloated

If you want fewer resets, check this setting:

openclaw config get agents.defaults.compaction.reserveTokensFloor

If it’s lower than 20000, raise it. I’d use 24000 for some extra headroom.

Config example:

#

{
  agents: {
    defaults: {
      compaction: {
        reserveTokensFloor: 24000
      }
    }
  }
}

Then restart the gateway:

openclaw gateway restart

#

One important detail: 20000 is already the default floor in the docs, so if you still saw that message, either:

your config lowered it,
the thread was just very long,
or there was a lot of tool output/history in that session

If it keeps happening even after that, the next things to tune are:

/compact usage
agents.defaults.compaction.keepRecentTokens
session pruning

Docs:

#

If you paste:

openclaw config get agents.defaults.compaction.reserveTokensFloor
openclaw config get agents.defaults.compaction.keepRecentTokens

I can tell you a sane value for your setup.

past cosmos Apr 13, 2026, 1:50 PM

#

Config path not found: agents.defaults.compaction.keepRecentTokens

pliant riverBOT Apr 13, 2026, 1:51 PM

#

Yep, that just means the key is not set yet in your config, not that it’s invalid.

keepRecentTokens is a real compaction setting, but openclaw config get can say “path not found” when that path is currently unset.

So you can just set it explicitly:

openclaw config set agents.defaults.compaction.reserveTokensFloor 24000
openclaw config set agents.defaults.compaction.keepRecentTokens 20000
openclaw gateway restart

If you want the minimal fix, this alone is enough to try first:

openclaw config set agents.defaults.compaction.reserveTokensFloor 24000

#

openclaw gateway restart

So:

path not found = unset
not “this config key doesn’t exist”

Docs:

If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person. 🎉

past cosmos Apr 13, 2026, 1:53 PM

#

If the bot doesn't send a pairing code, check the gateway logs:
bashopenclaw gateway logs --follow
Give me the updated command this command I think is old not working

pliant riverBOT Apr 13, 2026, 1:53 PM

#

Yep, that one is old/broken formatting.

The current command is:

openclaw logs --follow

If you also want to check whether the gateway itself is up:

openclaw gateway status

If the RPC/log stream is unavailable, fall back to the latest file log:

#

tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

So, short version:

old/wrong: openclaw gateway logs --follow
current: openclaw logs --follow

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

past cosmos Apr 13, 2026, 1:55 PM

#

I have created many bots and connected with my open claw agent but it is not giving me pairing code for all the botson my telegram can you give me a comment that will solve this problem?

pliant riverBOT Apr 13, 2026, 1:56 PM

#

The main gotcha is this:

Telegram pairing is per bot account, and /start alone does not generate a pairing code.

So for multiple Telegram bots, check pairing per account:

openclaw pairing list --channel telegram --account <botAccountId>
openclaw pairing approve --channel telegram --account <botAccountId> <CODE>

If you want to skip pairing headaches for your own bots, the cleaner setup is:

set dmPolicy: "allowlist"
put your numeric Telegram user ID in allowFrom
do that for each Telegram account/bot

#

Important multi-bot detail: named Telegram accounts do not automatically inherit the default account’s allowlist.

So for multi-account Telegram, you usually want account-scoped config like:

{
  channels: {
    telegram: {
      accounts: {
        bot1: {
          dmPolicy: "allowlist",
          allowFrom: ["123456789"]
        },
        bot2: {
          dmPolicy: "allowlist",
          allowFrom: ["123456789"]

#

To find your Telegram user ID:

DM the bot
run:

openclaw logs --follow

#

read from.id

So the short answer is:

pairing code only appears for an unknown DM sender
/start by itself is not enough
with many bots, use --account <id>
for owner-only bots, allowlist your numeric user ID instead of relying on pairing

Docs:

If you paste your Telegram accounts config shape, I can show you the exact block to add.

past cosmos Apr 13, 2026, 1:58 PM

#

⚠️ Model login failed on the gateway for chutes. Please try again. If this keeps happening, re-auth with openclaw models auth login --provider chutes. Why I'm getting this error every time I create a new bot and try to message it!!

pliant riverBOT Apr 13, 2026, 1:59 PM

#

That error is not about the new Telegram bot itself.
It means your gateway cannot authenticate to Chutes, so every new bot that tries to answer hits the same model-auth failure.

So the real fix is on the gateway host (the machine running openclaw gateway), not in Telegram.

Run this there:

openclaw models status
openclaw models auth login --provider chutes
openclaw doctor

If you’re running a long-lived VPS/server, I’d honestly use a Chutes API key instead of relying on login refresh:

#

openclaw onboard --auth-choice chutes-api-key

Or put the key in:

~/.openclaw/.env

like:

CHUTES_API_KEY=...

then restart:

#

openclaw gateway restart
openclaw models status

Important bit:

creating a new bot does not create new model auth
all those bots still use the same gateway model provider auth
so if Chutes auth is broken once, they all fail

Docs:

If you paste openclaw models status, I can tell you whether it’s an expired login, missing env key, or auth-profile issue.

past cosmos Apr 13, 2026, 2:03 PM

#

Can you tell me more about inside the jason like the path that you give me i'm not finding the path in my vpsexplorer

pliant riverBOT Apr 13, 2026, 2:04 PM

#

Yep, the confusing part is the ~.

~/.openclaw/... means inside the home folder of the user running OpenClaw.

On a typical Ubuntu VPS, if your user is ubuntu, these paths are usually:

config: /home/ubuntu/.openclaw/openclaw.json
env file: /home/ubuntu/.openclaw/.env
exec approvals: /home/ubuntu/.openclaw/exec-approvals.json

Two common reasons you “can’t find it” in a VPS explorer:

.openclaw is a hidden folder
Anything starting with . is hidden unless you enable Show hidden files
The gateway may be running under a different user
For example root, which would make the path:

#

/root/.openclaw/openclaw.json
/root/.openclaw/.env

Quick checks:

echo $HOME
ls -la ~/.openclaw

If you want to see where OpenClaw thinks the config is, run:

openclaw gateway status
openclaw health --verbose

#

So for you, try looking in:

/home/ubuntu/.openclaw/

and make sure your VPS explorer is showing hidden folders.

Docs:

If you paste the output of:

echo $HOME

#

ls -la ~/.openclaw

I can tell you the exact file path to open.

past cosmos Apr 13, 2026, 2:15 PM

#

OK there isno .env file

pliant riverBOT Apr 13, 2026, 2:15 PM

#

That’s totally fine, .env is optional. If it’s missing, just create it.

For a VPS, this is usually the easiest fix for Chutes auth:

mkdir -p ~/.openclaw
cat >> ~/.openclaw/.env <<'EOF'
CHUTES_API_KEY=your_chutes_api_key_here
EOF
openclaw gateway restart
openclaw models status

A couple of important details:

.env is a plain text file, not JSON
format is just:

#

KEY=value

So for example:

CHUTES_API_KEY=abc123

If you prefer OAuth instead of an API key, you do not need .env, and you can do:

openclaw models auth login --provider chutes

But for a long-running VPS, I’d use the API key in ~/.openclaw/.env. It’s usually more reliable.

#

Docs:

If you want, I can also show you the exact openclaw.json vs .env difference so you know which file is for what.

past cosmos Apr 13, 2026, 2:19 PM

#

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

chutes effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=2 (oauth=1, token=0, api_key=1) | chutes:shafin013=OAuth (shafin013), chutes:default=cpk_d942...4e05PgvN | env=cpk_d942...4e05PgvN | source=env: CHUTES_API_KEY

OAuth/token status

chutes
- chutes:shafin013 (shafin013) ok expires in 0m

pliant riverBOT Apr 13, 2026, 2:20 PM

#

Nice, this output explains it.

The problem is this line:

chutes:shafin013 (shafin013) ok expires in 0m

So your OAuth profile is basically expiring right now, and fresh bot/session starts keep hitting that broken/expiring Chutes login.

But you also already have an API key profile:

chutes:default=cpk_...
source=env: CHUTES_API_KEY

#

For a VPS, I’d stop using the expiring OAuth profile and force OpenClaw to use the API key profile instead.

Run this on the gateway host:

openclaw models auth order get --provider chutes --agent main
openclaw models auth order set --provider chutes --agent main chutes:default
openclaw gateway restart
openclaw models status --probe

Why this helps:

chutes:shafin013 = OAuth, expiring now
chutes:default = your API key, better for a VPS
new bots are not the root problem, they just trigger a fresh model auth check

#

If you want to keep OAuth instead, re-login:

openclaw models auth login --provider chutes

But honestly, for a server, API key + auth order pinned to chutes:default is the cleaner fix.

Docs:

If auth order set errors, paste that output and I’ll give you the next step.

past cosmos Apr 13, 2026, 2:21 PM

#

IF other agents so if we choose api key then we should change all of those agent setting with one command is there any

pliant riverBOT Apr 13, 2026, 2:23 PM

#

Yes, but there are 2 different scopes:

1) `models auth order set`

This is per-agent only.
So if you run:

openclaw models auth order set --provider chutes --agent main chutes:default

that only affects main.

2) Global config, recommended for all agents

If you want all agents to prefer the Chutes API key profile, set the global auth order in ~/.openclaw/openclaw.json:

#

{
  auth: {
    order: {
      chutes: ["chutes:default"]
    }
  }
}

Then restart:

openclaw gateway restart
openclaw models status --probe

#

So the short answer is:

one CLI auth-order command for every agent: no
one global config change for all agents: yes ✅

If most of your bots all route through the same default agent anyway, then setting just main may already be enough.

Docs:

If you want, I can show you exactly where to paste that auth.order block inside your current openclaw.json.

past cosmos Apr 13, 2026, 2:25 PM

#

"auth": {
"profiles": {
"chutes:shafin013": {
"provider": "chutes",
"mode": "oauth"
},
"chutes:default": {
"provider": "chutes",
"mode": "api_key"
}
},
"order": {
"chutes": [
"chutes:default",
"chutes:shafin013"
]
}
},
Is it okok

pliant riverBOT Apr 13, 2026, 2:26 PM

#

Yep, that is valid ✅

But for your case, I’d make it even cleaner.

Right now you have:

"chutes": [
  "chutes:default",
  "chutes:shafin013"
]

That means:

try the API key first
if that fails, fall back to the OAuth profile

#

If your goal is to stop the expiring OAuth from causing trouble, I’d use only:

"auth": {
  "profiles": {
    "chutes:shafin013": {
      "provider": "chutes",
      "mode": "oauth"
    },
    "chutes:default": {
      "provider": "chutes",
      "mode": "api_key"
    }
  },
  "order": {
    "chutes": ["chutes:default"]

#

}
}

Then restart:

openclaw gateway restart
openclaw models status --probe

So:

your version: okay
my recommendation: better to keep only chutes:default

#

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it. 🎉

past cosmos Apr 13, 2026, 4:29 PM

#

⚠️ Context limit exceeded. I've reset our conversation to start fresh - please try again.

To prevent this, increase your compaction buffer by setting agents.defaults.compaction.reserveTokensFloor to 20000 or higher in your config.

As I think you should know The api provider I am using the same provider for my six agent so I think when I communicate with the six agent at a time it is giving me this error I don't know you know the best So what should be the solution give me a one to go solution

pliant riverBOT Apr 13, 2026, 4:29 PM

#

The same provider across 6 agents is not the direct cause.
This error is mostly per-session context bloat, not “too many agents on one API key”.

If you want one clean fix, do this on the gateway host:

openclaw config set agents.defaults.compaction.mode safeguard
openclaw config set agents.defaults.compaction.reserveTokensFloor 24000
openclaw config set agents.defaults.compaction.keepRecentTokens 20000
openclaw gateway restart

Then start fresh with:

/new

#

Why I’m recommending this:

reserveTokensFloor 24000 gives more headroom
keepRecentTokens 20000 preserves recent context better
mode safeguard makes compaction more protective

So the short answer is:

not really a 6-agent same-provider problem
yes, tune compaction once globally

Docs:

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

past cosmos Apr 13, 2026, 4:30 PM

#

Man I have already done that I have make that 1,00,000 now also not working

#

And the thing that I have observed it is only giving this error with three of my agent the remaining agent is working.

pliant riverBOT Apr 13, 2026, 4:31 PM

#

Okay, then reserveTokensFloor is not the real fix here.

And honestly, setting it to 100000 is not helping. The real problem is more likely tool-result/session bloat, not the reserve floor.

If you want one “do this now” fix, I’d use this instead:

openclaw config set agents.defaults.compaction.mode safeguard
openclaw config set agents.defaults.compaction.reserveTokensFloor 24000
openclaw config set agents.defaults.contextPruning.mode cache-ttl
openclaw config set agents.defaults.contextPruning.ttl 5m
openclaw gateway restart

Then in the bloated chats, do:

#

/new

Why this is better:

reserveTokensFloor alone only changes headroom
context pruning trims old tool outputs before they blow up the prompt
that is usually the real fix when lots of agent/tool output is piling up

So yes, my recommendation is:

put reserveTokensFloor back to 24000
turn on context pruning
restart
start fresh sessions

#

Docs:

If that still fails after a fresh /new, then I’d want openclaw --version and openclaw models status again, because then it may be a model-context issue, not just compaction.

#

Ah, that changes it a lot.

If only 3 agents are failing and the others are fine, then this is probably not a global provider problem anymore.

It’s usually one of these for those 3 agents:

old bloated sessions on those agents
per-agent auth order override still pointing at the bad Chutes OAuth profile
per-agent model/config override different from the working agents

So the best next move is to check the broken agents only:

openclaw models status --agent <agentId>
openclaw models auth order get --provider chutes --agent <agentId>

#

If you already set the global Chutes auth order to chutes:default, then for the broken agents I’d clear any per-agent override so they inherit the global setting:

openclaw models auth order clear --provider chutes --agent <agentId>

Then:

openclaw gateway restart

And in the affected chats, start fresh:

/new

#

So, short version:

all agents broken = global issue
only 3 agents broken = agent-specific override or stale session

If you paste the 3 broken agent IDs plus:

openclaw models status --agent <id>
openclaw models auth order get --provider chutes --agent <id>

I can tell you exactly what is different from the working ones.

past cosmos Apr 14, 2026, 3:16 AM

#

Sometimes I see when I tell something to my agent its thing for some time and like I see literally he is typeed The message sometime but like then it is gone my I give I tell him some question or I give him some comment and the next message where it should give me reply I do not get any reply from him just he will stop there and again when I give him follow up question he didn't reply me it is so weierd!!

pliant riverBOT Apr 14, 2026, 3:16 AM

#

Yeah, that usually means this:

the agent started a draft/preview
then the run failed before the final reply was sent

So the “typed message appears, then disappears” part can be normal preview streaming, but the missing final reply means something is breaking after that.

On Discord, check these 3 things first:

openclaw gateway status
openclaw logs --follow
openclaw models status --agent <broken-agent-id>

Very likely causes in your setup:

#

Chutes auth/profile issue on that agent
context/session blow-up on that agent
preview streaming showing a draft, then the run errors out

If you want to stop the confusing disappearing draft behavior on Discord, turn preview streaming off:

openclaw config set channels.discord.streaming off
openclaw gateway restart

That won’t fix the root error, but it will stop the fake “it was typing and then vanished” effect.

So my recommendation is:

one practical fix

#

openclaw config set channels.discord.streaming off
openclaw gateway restart
openclaw logs --follow

Then send one test message to a broken agent and watch the logs.
That will usually show the real cause immediately.

Docs:

If you paste the log lines from one failed reply, I can decode exactly what is killing it.

past cosmos Apr 14, 2026, 3:18 AM

#

No no I am not discord The problem that is occurring is in Telegram and open claw web ui

pliant riverBOT Apr 14, 2026, 3:19 AM

#

Ah, got it, thanks. That actually fits Telegram pretty well.

On Telegram, preview streaming is on by default (partial), so OpenClaw can:

show a temporary preview message
keep editing it while thinking
either turn that same message into the final reply, or clean it up and send the final message

So the “I saw it typing / saw a message / then it disappeared” part can be normal preview behavior.

The bad part is this:

if the final send/edit fails, you end up seeing the preview disappear and then no final reply

So the clean test is:

#

openclaw config set channels.telegram.streaming off
openclaw gateway restart
openclaw logs --follow

Then send one test message from Telegram.

Why this helps:

turning streaming off removes the confusing temporary preview behavior
if the reply still fails, the logs will show the real error clearly

So for Telegram, my one practical fix is:

#

openclaw config set channels.telegram.streaming off
openclaw gateway restart

Then test again.

Docs:

If you still get no reply after turning Telegram streaming off, paste the log lines from openclaw logs --follow right after one failed message, and I’ll decode it.

past cosmos Apr 14, 2026, 3:20 AM

#

🦞 OpenClaw 2026.4.11 (769908e) — Making 'I'll automate that later' happen now.

Error: Config validation failed: channels.telegram: channels.telegram.streamMode, channels.telegram.streaming (scalar), chunkMode, blockStreaming, draftChunk, and blockStreamingCoalesce are legacy; use channels.telegram.streaming.{mode,chunkMode,preview.chunk,block.enabled,block.coalesce} instead. Run "openclaw doctor --fix".

pliant riverBOT Apr 14, 2026, 3:21 AM

#

Yep, that’s the issue. Your Telegram config is still using the legacy streaming keys.

So first migrate the config:

openclaw doctor --fix

Then disable Telegram preview streaming with the new path:

openclaw config set channels.telegram.streaming.mode off
openclaw gateway restart

So the updated flow is:

#

openclaw doctor --fix
openclaw config set channels.telegram.streaming.mode off
openclaw gateway restart

Your error is basically saying the old keys like these are no longer accepted:

channels.telegram.streamMode
channels.telegram.streaming (scalar)
chunkMode
blockStreaming
draftChunk
blockStreamingCoalesce

They now live under the nested shape:

channels.telegram.streaming.mode
channels.telegram.streaming.chunkMode

#

channels.telegram.streaming.preview.chunk
channels.telegram.streaming.block.enabled
channels.telegram.streaming.block.coalesce

So yes, run doctor --fix first, then use the new channels.telegram.streaming.mode path.

Docs:

If doctor --fix prints migration changes, paste them here and I’ll sanity-check them.

past cosmos Apr 14, 2026, 3:31 AM

#

And what about the open claw UI problem the message disappearing also from that UI chat interface.

pliant riverBOT Apr 14, 2026, 3:32 AM

#

Yeah, if it happens in both Telegram and the OpenClaw UI, then I would not treat it as a UI-only bug.

That usually means the underlying agent run is aborting/failing, and the two surfaces just show that failure differently:

Telegram: preview message appears, then disappears
Web UI: partial text/typing can show up, then the run stops

The Web UI docs actually mention that aborted runs can keep partial assistant output visible. So that weird disappearing/half-reply behavior fits an aborted run.

So the important point is:

same root problem, different surface behavior

What to do:

#

openclaw logs --follow

Then reproduce one failed reply from Telegram or Web UI and look at the log right after it fails.

If you want the best quick check too:

openclaw gateway status
openclaw status --all

Since you already had:

Chutes auth issues
context/reset issues

#

legacy Telegram streaming config issues

I’m pretty confident the UI weirdness is a symptom, not the main bug.

Docs:

If you paste the log lines from one failed run, I can tell you whether it’s:

model auth
context overflow
send/edit failure
or session abort/reset

past cosmos Apr 14, 2026, 3:37 AM

#

device=fa752f0f9cefc28b47335dfc948603a55fb2f2d7f1b751c2d407a564005f0842 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=0b692223-90fd-40fc-b0f2-8e6dcb6e502b
03:36:06+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
03:36:06+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
gateway connect failed: GatewayClientRequestError: pairing required

#

??

pliant riverBOT Apr 14, 2026, 3:42 AM

#

That log actually shows the exact problem.

This is not the normal exec approval prompt. It’s a device pairing / scope-upgrade problem.

Your device:

fa752f0f9cefc28b47335dfc948603a55fb2f2d7f1b751c2d407a564005f0842

currently has only:

scopesFrom=operator.read

but it’s trying to connect with:

#

scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write

So OpenClaw is rejecting it with:

GatewayClientRequestError: pairing required

Fix

Run this on the machine running openclaw gateway:

openclaw devices list

#

openclaw devices approve <requestId>

Important: if it keeps retrying, run openclaw devices list again right before approving, because the requestId can change.

Why you keep getting asked every time

Because that device/token only has operator.read, so every action that needs write/admin-ish scopes triggers another upgrade request.

So yes, this is why it feels like hell 😅

Docs:

If you paste the output of openclaw devices list, I can tell you which requestId to approve.

#

Simple version:

Your device is paired with read-only access right now, so OpenClaw keeps asking to approve the upgrade.

Run this on the gateway/VPS host:

openclaw devices list
openclaw devices approve <requestId>

Use the requestId shown by devices list.

If it keeps changing, rerun openclaw devices list and approve the newest one.

That should stop the repeated pairing required prompts.

past cosmos Apr 14, 2026, 3:44 AM

#

Pending (1)
┌──────────────────────────────────────┬────────────────┬──────────┬────────────────────┬────────────┬────────┬────────┐
│ Request │ Device │ Role │ Scopes │ IP │ Age │ Flags │
├──────────────────────────────────────┼────────────────┼──────────┼────────────────────┼────────────┼────────┼────────┤
│ 2dbdb140-feff-4897-bf77-59cb27b6a7ae │ fa752f0f9cefc2 │ operator │ operator.admin, │ │ 4m ago │ repair │
│ │ 8b47335dfc9486 │ │ operator.read, │ │ │ │
│ │ 03a55fb2f2d7f1 │ │ operator.write, │ │ │ │
│ │ b751c2d407a564 │ │ operator. │ │ │ │
│ │ 005f0842 │ │ approvals, │ │ │ │
│ │ │ │ operator.pairing, │ │ │ │
│ │ │ │ operator.talk. │ │ │ │
│ │ │ │ secrets │ │ │ │
└──────────────────────────────────────┴────────────────┴──────────┴────────────────────┴────────────┴────

#

Paired (2)
┌──────────────────────────────┬────────────┬────────────────────────────────────────────────┬────────────┬────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├──────────────────────────────┼────────────┼────────────────────────────────────────────────┼────────────┼────────────┤
│ gateway:doctor.memory.status │ operator │ operator.read │ operator │ │
│ 38d8f350a4c76a1bcaa522d81f2a │ operator │ operator.admin, operator.read, operator. │ operator │ │
│ 6af66d3280caea05306f9402b73b │ │ write, operator.approvals, operator.pairing │ │ │
│ 9facce41 │ │ │ │ │
└──────────────────────────────┴────────────┴────────────────────────────────────────────────┴────────────┴────────────┘
-bash: syntax error near unexpected token `newline'

pliant riverBOT Apr 14, 2026, 3:45 AM

#

Perfect, that’s the one.

Approve it with:

openclaw devices approve 2dbdb140-feff-4897-bf77-59cb27b6a7ae

That pending entry is for your device:

fa752f0f9cefc28b47335dfc948603a55fb2f2d7f1b751c2d407a564005f0842

After that, retry your agent command.

If it works, the repeated pairing required prompt should stop.

#

The -bash: syntax error near unexpected token 'newline' part usually means the shell saw literal angle brackets like <requestId>.

So run the command exactly like this, with no < >:

openclaw devices approve 2dbdb140-feff-4897-bf77-59cb27b6a7ae

Then check again:

openclaw devices list

Important: I still don’t see your device fa752f0f... in that paired list yet, so I don’t think the approval actually finished.

If that request is gone, do this:

#

trigger the failing command once
run openclaw devices list
approve the new request ID it shows

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

past cosmos Apr 14, 2026, 3:46 AM

#

ubuntu@hunter-a1-flex:~$ openclaw devices approve 2dbdb140-feff-4897-bf77-59cb27b6a7ae

🦞 OpenClaw 2026.4.11 (769908e) — Automation with claws: minimal fuss, maximal pinch.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
unknown requestId

pliant riverBOT Apr 14, 2026, 3:47 AM

#

That means the old request ID is already stale.

unknown requestId here usually means the device retried and OpenClaw issued a new pending request.

Do this:

openclaw devices list

Find the new pending request for device:

fa752f0f9cefc28b47335dfc948603a55fb2f2d7f1b751c2d407a564005f0842

Then approve that new ID:

#

openclaw devices approve <new-request-id>

If no pending request shows up:

trigger the failing agent command once
run openclaw devices list again
approve the fresh request ID immediately

So, short version: the request changed, approve the newest one, not 2dbdb140-... anymore.

past cosmos Apr 14, 2026, 3:48 AM

#

gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
Approved fa752f0f9cefc28b47335dfc948603a55fb2f2d7f1b751c2d407a564005f0842 (1011ddd2-8eaf-4da9-9ab5-39738980efc1)

pliant riverBOT Apr 14, 2026, 3:49 AM

#

Nice, that approved the right device 🎉

This line is the important part:

Approved fa752f0f9cefc28b47335dfc948603a55fb2f2d7f1b751c2d407a564005f0842

Now retry your agent command.

That repeated pairing required prompt should be gone now.

If it still happens after this, run:

openclaw devices list

#

and paste the new output, but I think you’re past the main blocker.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

past cosmos Apr 14, 2026, 3:52 AM

#

fa752f0f9cefc28b │ operator │ operator.read, operator.admin, operator.write, operator. │ operator │ │
│ 47335dfc948603a5 │ │ approvals, operator.pairing, operator.talk.secrets │ │ │
│ 5fb2f2d7f1b751c2 │ │ │ │ │
│ d407a564005f0842 │ │ │ │ │
│ 38d8f350a4c76a1b │ operator │ operator.admin, operator.read, operator.write, operator. │ operator │ │
│ caa522d81f2a6af6 │ │ approvals, operator.pairing │ │ │
│ 6d3280caea05306f │ │ │ │ │
│ 9402b73b9facce41 │ │ │

Here what is the second device like I am seeing 2 operators so is it the web ui and also my question is like I was chatting with it from Telegram in the yesterday night but why suddenly I am getting this error because it was paired

pliant riverBOT Apr 14, 2026, 3:53 AM

#

Yep, that makes sense now.

Why you see 2 `operator` devices

Those are paired admin/operator clients, not Telegram chats.

So the second one is probably another thing like:

a browser Control UI session
another CLI shell / machine
another device that was paired earlier

It is not your Telegram conversation itself.

Why it suddenly started failing even though it was paired before

Because this was a repair / scope-upgrade request.

#

Your device was known already, but it came back asking for broader scopes, which matches the earlier log:

scopesFrom=operator.read
scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write

So OpenClaw basically said:

"I know this device, but the token/scopes I have for it are no longer enough, approve the repaired one."

That can happen after an update, token refresh, device-token mismatch, or a reconnect that asks for more scopes than the old cached token had.

Short version

Telegram was not the problem
your operator device token was the problem

#

you approved the repaired device
that should be the fix

About the second device

If you recognize it, leave it alone.

If you don’t recognize it and you want to remove it later, you can do:

openclaw devices remove <deviceId>

But don’t remove it unless you’re sure it’s not one of your browser/CLI sessions.

If this fixed the issue, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

past cosmos Apr 14, 2026, 3:58 AM

#

I am getting output from my web ui chat interface but the output is not showing on my telegram chat interface but I was interacting with my agent in telegram it is not giving me output in the telegram sometimes this happens why

pliant riverBOT Apr 14, 2026, 3:59 AM

#

If the answer shows up in Web UI but not Telegram, then the agent usually did finish and the problem is on the Telegram delivery step.

Most likely it’s one of these:

you’re looking at a Web UI session
WebChat replies route back to WebChat, not Telegram
Telegram preview/send failed
Telegram can show a temporary preview, then the final send/edit fails, so Web UI has the text but Telegram doesn’t

Since you said this happens sometimes, I’d treat it as a Telegram delivery / preview-streaming issue, not a model issue.

Best quick fix

On the gateway host:

#

openclaw doctor --fix
openclaw config set channels.telegram.streaming.mode off
openclaw gateway restart

That disables the Telegram live preview/edit behavior, which is the usual source of the “shows here, disappears there” confusion.

When it happens again

Run:

openclaw logs --follow

Then send one Telegram message and watch for Telegram sendMessage / editMessageText errors.

#

Docs:

If you want, paste one log snippet from a failed Telegram reply and I’ll tell you exactly which step is breaking.

rapid martenBOT Apr 14, 2026, 4:16 AM

#

past cosmos Apr 14, 2026, 4:41 AM

#

@pliant river

pliant riverBOT Apr 14, 2026, 4:41 AM

#

I’m here 🦐

If Telegram is still dropping replies, send me one failed-run log snippet from:

openclaw logs --follow

right after you trigger a Telegram message, and I’ll pinpoint the exact break.

past cosmos Apr 14, 2026, 4:42 AM

#

• agents_list shows only "main" agent configured
• No subagents available to delegate to
• So I handled it myself as a fallback

Can you tell me where is the problem here

pliant riverBOT Apr 14, 2026, 4:42 AM

#

Yep, the problem there is:

you only have main configured, and no extra agent ids are allowed for subagent spawning.

So this result:

agents_list shows only "main"
No subagents available to delegate to

means OpenClaw has nothing else to spawn.

What’s missing

You need both:

#

extra agents in agents.list
a subagent allowlist via subagents.allowAgents

Example

agents: {
  defaults: {
    subagents: {
      allowAgents: ["research", "coder"]
    }
  },
  list: [
    { id: "main", default: true },
    { id: "research" },
    { id: "coder" }

#

]
}

If you want main to be able to target anything:

agents: {
  defaults: {
    subagents: {
      allowAgents: ["*"]
    }
  }
}

#

Short version

Right now the problem is config, not the tool itself.

only main exists
no other target agents are available
so OpenClaw falls back to handling it itself

Docs: https://docs.openclaw.ai/tools/subagents

If you want, paste your agents config block and I’ll tell you the exact JSON5 to add.

past cosmos Apr 14, 2026, 4:44 AM

#

Okay right now I am using multi agent setup so tell me how to write this configure how to do so that all agent is ready to go with my command with my orchestrator agent the main agent command so how to craft this configuration

pliant riverBOT Apr 14, 2026, 4:45 AM

#

Yep. If you want main to act as the orchestrator and be able to call the other agents, write it like this in your JSON5 config under agents:

{
  agents: {
    defaults: {
      subagents: {
        allowAgents: ["research", "coder", "browser"],
        runTimeoutSeconds: 900,
      },
    },

    list: [
      {
        id: "main",
        default: true,

#

        subagents: {
          allowAgents: ["research", "coder", "browser"],
        },
      },

      {
        id: "research",
        model: "openai/gpt-5.4",
      },

      {
        id: "coder",
        model: "openai/gpt-5.4",
      },

#

      {
        id: "browser",
        model: "openai/gpt-5.4",
      },
    ],
  },
}

If you want `main` to be able to target any agent

Use this instead:

subagents: {

#

  allowAgents: ["*"]
}

After saving

Restart the gateway:

openclaw gateway restart

Then test:

#

openclaw config get agents.list

and from the agent side, agents_list should start showing:

research
coder
browser

Important

The key part is this:

subagents: {

#I'm getting an approval request error like it is bugging me every time I command my agent to do >>>

Option 1, recommended

Option 2

1) models auth order set

2) Global config, recommended for all agents

one practical fix

Fix

Why you keep getting asked every time

Why you see 2 operator devices

Why it suddenly started failing even though it was paired before

Short version

About the second device

Best quick fix

When it happens again

What’s missing

Example

Short version

If you want main to be able to target any agent

After saving

Important

1) `models auth order set`

Why you see 2 `operator` devices

If you want `main` to be able to target any agent