Getting swamped with approval requests

[safe oxide]

I am running OpenClaw on a Raspberry Pi. After the update to 2026.4.4 I have a lot of these messages in the log:

Apr 17 14:17:21 Doris node[958]: 2026-04-17T14:17:21.349+02:00 [gateway] security audit: device access upgrade requested reason=scope-upgrade device=c765e66648ed12a6d69400441b9cbfd9e5f56f2c01eecb70de0758c3e9366ad6 ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.approvals client=gateway-client conn=b0c919ec-2598-4584-af0e-52bfc4eaf0d6
Apr 17 14:17:22 Doris node[958]: 2026-04-17T14:17:22.172+02:00 [telegram/native-approvals] connect error: pairing required
Apr 17 14:17:22 Doris node[958]: 2026-04-17T14:17:22.177+02:00 gateway connect failed: GatewayClientRequestError: pairing required
Apr 17 14:17:22 Doris node[958]: 2026-04-17T14:17:22.204+02:00 [telegram] failed to start native approval handler: GatewayClientRequestError: pairing required
Apr 17 14:17:22 Doris node[958]: 2026-04-17T14:17:22.257+02:00 [ws] closed before connect conn=b0c919ec-2598-4584-af0e-52bfc4eaf0d6 peer=127.0.0.1:34140->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=pairing required

There are 2, 3 of these parts per minute. The conn-value is constantly changing. What can I do to get rid of them?

[sullen sky]

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

[molten surge]

Let me verify the docs and the exact error path in the source so I can give you the real fix, not a guess.

That usually means Telegram native exec approvals started up, but the paired operator device only has operator.read, not operator.approvals.

Your key line is this one:

scopesFrom=operator.read scopesTo=operator.approvals

So OpenClaw keeps retrying the Telegram native approval handler, the gateway says “pairing required”, and each retry gets a new conn=.... That changing conn value is normal.

Two ways to stop it:

1. If you want Telegram approval prompts/buttons, approve the scope upgrade once:

openclaw --version
openclaw devices list
openclaw devices approve <requestId>
openclaw gateway restart

2. If you do not use Telegram as a native approval client, disable it explicitly:

{
  channels: {
    telegram: {
      execApprovals: {
        enabled: false
      }
    }
  }
}

Then restart:

openclaw gateway restart

Docs:

• https://docs.openclaw.ai/cli/devices
• https://docs.openclaw.ai/tools/exec-approvals
• https://docs.openclaw.ai/channels/telegram
• https://docs.openclaw.ai/gateway/troubleshooting

If you paste openclaw devices list and openclaw --version, I can tell you which fix is the right one for your setup.

[safe oxide]

~ $ openclaw --version
OpenClaw 2026.4.14 (323493f)

~ $ openclaw devices list

🦞 OpenClaw 2026.4.14 (323493f) — I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
Direct scope access failed; using local fallback.
Pending (1)
┌──────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────┬──────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────┬──────────┬────────┐
│ Request │ Device │ Role │ Scopes │ IP │ Age │ Flags │
├──────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────┼──────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────────┼──────────┼────────┤
│ bc202b93-7ba4-4801-960d-1a21f06131cd │ c765e66648ed12a6d69400441b9cbfd9e5f56f2c01eecb70de0758c3e9366ad6 │ operator │ operator.approvals, operator.admin, operator.read, operator.write, operator.pairing, operator.talk.secrets │ │ just now │ repair │
└──────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────┴──────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────────┴──────────┴────────┘

Paired (3)
┌──────────────────────────────────────────────────────────────────────────────────────────┬────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────────┬───────────────────────────────────┬────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├──────────────────────────────────────────────────────────────────────────────────────────┼────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────────┼───────────────────────────────────┼────────────┤

[molten surge]

Nice, that helps, you’re actually on 2026.4.14, so this is probably not just “old 2026.4.4 behavior”.

I’d treat it as a real pending scope upgrade, not a generic version mismatch.

What I’d do next:

openclaw devices list

If you see a pending request for that device asking for operator.approvals, then either:

1. Approve it if you want Telegram native exec approvals:

   openclaw devices approve <requestId>
   openclaw gateway restart
   

2. Disable Telegram native exec approvals if you do not use them:

   {
     channels: {
       telegram: {
         execApprovals: {
           enabled: false
         }
       }
     }
   }
   

   then:

   openclaw gateway restart
   

So the short version is, this is most likely:

• Telegram native approvals auto-starting
• requesting operator.approvals
• your stored paired device only having operator.read
• retry loop => new conn= every time

Paste openclaw devices list and I can tell you exactly which of the two applies.

[safe oxide]

│ c765e66648ed12a6d69400441b9cbfd9e5f56f2c01eecb70de0758c3e9366ad6 │ operator │ operator.read │ operator │ │
│ 89189a678a44180817ecbabcf6de4637ab54443bcab6ec2d64514141e2bf9905 │ operator │ operator.admin, operator.approvals, operator.pairing, operator.read, operator.write │ operator │ │
│ ea49b55147d912718399cbe48d23ec2640a1dd95ce080108904c906630a8f69f │ operator │ operator.admin, operator.approvals, operator.pairing, operator.read, operator.write │ operator │ │
└──────────────────────────────────────────────────────────────────────────────────────────┴────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────────┴───────────────────────────────────┴────────────┘

[molten surge]

Yep, that confirms it.

This is the exact thing causing the log spam: there is a pending device repair / scope upgrade for the same device ID from your logs.

If this is your own Pi / local OpenClaw instance, approve it:

openclaw devices approve bc202b93-7ba4-4801-960d-1a21f06131cd
openclaw gateway restart

That should stop the repeated:

• security audit: device access upgrade requested
• telegram/native-approvals ... pairing required
• changing conn=... reconnect attempts

A couple notes:

• The Direct scope access failed; using local fallback. line is fine here.
• If the request ID changed before you approve, run openclaw devices list again and use the new one.
• If you do not want Telegram native approvals at all, the alternative is still to disable:
  channels.telegram.execApprovals.enabled: false

So my recommendation is, approve this pending repair request first. It looks like the clean fix.

Looks like the paste got cut off before the useful part 😅

Since we already have the pending request ID, I’d just try the fix now:

openclaw devices approve bc202b93-7ba4-4801-960d-1a21f06131cd
openclaw gateway restart

A couple gotchas:

• openclaw devices approve without the exact ID does not approve, it only previews.
• If it says request not found, the retry loop probably rotated the pending request. Then run:

  openclaw devices list
  

  and paste the full Pending section again.

If approval works, those repeated pairing required Telegram/native-approvals log lines should stop.

Yep, that’s the culprit.

The device from your log,

c765e66648ed12a6d69400441b9cbfd9e5f56f2c01eecb70de0758c3e9366ad6

is already paired, but it only has:

operator.read

while your other paired operator devices have the full scope set.

So OpenClaw keeps trying to repair / upgrade that device for Telegram native approvals, gets pairing required, and retries.

Best fix

Approve the pending repair request for that same device:

openclaw devices list
openclaw devices approve <current-requestId>
openclaw gateway restart

Use the current pending request ID from the Pending section, not the device ID.

If the repair request keeps rotating or approval is annoying

Remove just that stale device record and let it re-pair cleanly:

openclaw devices remove c765e66648ed12a6d69400441b9cbfd9e5f56f2c01eecb70de0758c3e9366ad6
openclaw devices list
openclaw devices approve <new-requestId>
openclaw gateway restart

If you do not want Telegram native approvals at all

Disable them instead:

channels.telegram.execApprovals.enabled: false

So, short version: that one paired device is under-scoped and stale. Repair or re-pair it, and the log spam should stop.

[safe oxide]

~ $ openclaw devices remove c765e66648ed12a6d69400441b9cbfd9e5f56f2c01eecb70de0758c3e9366ad6

🦞 OpenClaw 2026.4.14 (323493f) — Shell yeah—I'm here to pinch the toil and leave you the glory.

│
gateway connect failed: GatewayClientRequestError: pairing required
◇
[openclaw] Failed to start CLI: Error: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/joern/.openclaw/openclaw.json
Bind: loopback
at Object.onClose (file:///home/joern/.npm-global/lib/node_modules/openclaw/dist/call-lSOkBlVy.js:249:10)
at WebSocket.<anonymous> (file:///home/joern/.npm-global/lib/node_modules/openclaw/dist/client-CJI3Hi9b.js:386:24)
at WebSocket.emit (node:events:508:28)
at WebSocket.emitClose (/home/joern/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:273:10)
at Socket.socketOnClose (/home/joern/.npm-global/lib/node_modules/openclaw/node_modules/ws/lib/websocket.js:1346:15)
at Socket.emit (node:events:508:28)
at TCP.<anonymous> (node:net:346:12)

[molten surge]

Let me double-check the CLI behavior here, because devices list had a loopback fallback and remove clearly didn’t.

Ah, that part makes sense.

devices remove is the wrong tool in this specific state because only devices list and devices approve have the local loopback fallback when the gateway is stuck on pairing required.

So, skip remove for now and do this instead:

openclaw devices list
openclaw devices approve <current-requestId>
openclaw gateway restart

Use the request ID from the Pending section, not the device ID.

Why this works:

• devices list falls back to local pairing files