openclaw - 💡(How to fix) Fix [Bug]: CLI commands repeatedly trigger scope-upgrade requests + Telegram Native Approvals fails with pairing required, generating persistent pending approvals [1 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Every CLI invocation triggers a scope-upgrade audit event and the Telegram Native Approvals handler fails at startup with pairing required, producing persistent Pending entries and continuous code=1008 log noise despite successful Web UI approvals.

Steps to reproduce

1. Fresh install on macOS Tahoe (26.3.1), Apple Silicon M1, Node 24.15.0 via Homebrew: npm install -g openclaw@latest.
2. Run openclaw onboard --install-daemon with:
   • Gateway: loopback (127.0.0.1), token auth, default port 18789
   • Channel: Telegram only, dmPolicy = "allowlist" with one static user ID
   • Model provider: Google, gemini-2.5-flash
   • Skills/plugins: all skipped
3. Complete onboarding, let the gateway start, verify Telegram works.
4. Open the Web UI via SSH port-forward: ssh -L 18789:localhost:18789 user@host → http://127.0.0.1:18789/
5. Navigate to Nodes → Devices → Pending. Approve the "Telegram Native Approvals (default)" entry.
6. From CLI, run any read-only command, e.g. openclaw gateway status, openclaw devices list, openclaw config get tools.profile.
7. Refresh the Web UI Devices panel and tail ~/.openclaw/logs/gateway.err.log.

Expected behavior

• Once approved from the Web UI, the Telegram Native Approvals device should remain approved across gateway restarts and CLI invocations.
• The CLI should reuse its already-granted scopes (operator.approvals,operator.read) on subsequent connections rather than re-requesting a scope-upgrade to the full admin scope set on every invocation.
• No new Pending entry should appear in the Devices panel after a successful approval of the same device.

Actual behavior

Two distinct but related failures are observed:

1. CLI scope-upgrade on every invocation. Every CLI connection (including read-only commands) triggers a security audit event where roleFrom=operator and roleTo=operator (same role) but scopes expand from operator.approvals,operator.read to operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write. The connection is then closed with code=1008 reason=connect failed.

   Log excerpt (from ~/.openclaw/logs/gateway.err.log): 2026-04-17T16:30:07.100-05:00 [gateway] security audit: device access upgrade requested reason=scope-upgrade device=<redacted-64char-hash> ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.approvals,operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=2380f28e-d6d7-40a9-b1c5-d44dd9c56a7e 2026-04-17T16:30:07.125-05:00 [ws] closed before connect code=1008 reason=connect failed

2. Telegram Native Approvals startup failure. At gateway start, the Telegram Native Approvals handler fails with pairing required, followed by a code=1008 WebSocket close.

   Log excerpt: 2026-04-17T16:27:30.736-05:00 gateway connect failed: GatewayClientRequestError: pairing required 2026-04-17T16:27:30.740-05:00 [telegram] failed to start native approval handler: GatewayClientRequestError: pairing required 2026-04-17T16:27:30.743-05:00 [ws] closed before connect code=1008 reason=pairing required

Approvals issued from the Web UI are accepted at the moment but the Pending entry for the same device reappears on the next gateway restart or CLI invocation. The bot itself (Telegram conversational path) remains functional.

OpenClaw version

2026.4.15 (041266a)

Operating system

macOS Tahoe 26.3.1 (build 25D771280a)

Install method

npm global (npm install -g openclaw@latest), running as LaunchAgent ai.openclaw.gateway

Model

google/gemini-2.5-flash

Provider / routing chain

openclaw -> google/gemini-2.5-flash (primary), with openclaw -> zai/glm-4.7-flash configured as fallback (not exercised in this bug)

Additional provider/model setup details

Single-agent deployment (main, default). Telegram is the only active channel. dmPolicy = "allowlist" with exactly one user ID. No custom providers or baseUrl overrides. tools.profile = "full" at time of reproduction; the same behavior was also observed under the default tools.profile = "coding". Config file at ~/.openclaw/openclaw.json. Auth profiles stored at ~/.openclaw/agents/main/agent/auth-profiles.json.

Logs, screenshots, and evidence

Pattern from `~/.openclaw/logs/gateway.err.log` (representative sample; hundreds of similar lines per active session):
2026-04-17T16:27:30.736-05:00 gateway connect failed: GatewayClientRequestError: pairing required
2026-04-17T16:27:30.740-05:00 [telegram] failed to start native approval handler: GatewayClientRequestError: pairing required
2026-04-17T16:27:30.743-05:00 [ws] closed before connect conn=60cf6bd3-1ac2-4afc-bd28-32821e307fc7 peer=127.0.0.1:55796->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
2026-04-17T16:30:07.100-05:00 [gateway] security audit: device access upgrade requested reason=scope-upgrade device=<redacted-64char-hash> ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.approvals,operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=2380f28e-d6d7-40a9-b1c5-d44dd9c56a7e
2026-04-17T16:30:07.125-05:00 [ws] closed before connect conn=2380f28e-d6d7-40a9-b1c5-d44dd9c56a7e peer=127.0.0.1:55804->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

Device hash and connection IDs redacted/sample only. Full logs available on request.

Impact and severity

• Affected users/systems: Any loopback-bound gateway using Telegram as the sole channel with a static allowlist dmPolicy, on OpenClaw 2026.4.15. Not channel-specific beyond Telegram Native Approvals being the trigger.
• Severity: Annoying. Cosmetic to end users (the conversational bot works), but blocks effective diagnostics during setup and operation because the error log fills with repetitive entries that obscure real errors.
• Frequency: Always. Every gateway restart reproduces the Telegram Native Approvals failure. Every CLI invocation reproduces the scope-upgrade event.
• Consequence: Persistent noise in gateway.err.log (hundreds of lines per active session), persistent Pending entries in the Devices panel that cannot be permanently cleared, and onboarding confusion ("I approved it, why is it Pending again?"). No observed data loss, no failed message delivery.

Additional information

Not a regression I can pin to a specific good/bad version — this is the first install on this host and was observed continuously since the initial openclaw onboard on 2026-04-17 through version 2026.4.15.

No documented config key found to disable Telegram Native Approvals. When channels.telegram.dmPolicy = "allowlist" has a non-empty static allowlist, the Native Approvals feature is arguably redundant; an opt-out path (e.g. channels.telegram.nativeApprovals.enabled = false) would resolve the noise for this use case.

Possible investigation angles:

1. Audit the CLI connection flow on connect — is the client correctly reading its existing pinned scopes from ~/.openclaw/devices/ before issuing a scope-upgrade request? roleFrom == roleTo with differing scopes suggests the CLI unconditionally sends the "full" scope set and the server treats it as an upgrade rather than a no-op.
2. Check whether the telegram-native-approvals subsystem requires a separate pairing context from the user's device pairing and whether that context is persisted across gateway restarts.