OpenClaw connection Deepgramm | Friends of the Crustacean 🦞🤝 | Page 1

potent lintel May 12, 2026, 4:06 PM

#

I want to connect my OpenClaw, hosted on a managed VPS with Hoststinger, with Deepgram to transcribe Voice Messages on Telegram. But this error occurs and OpenClaw says the following:

gateway closed (1008): pairing required

What actually happens:

• openclaw devices approve ... requires gateway access
• but the same gateway already reports “pairing required” beforehand
• as a result, the approval cannot be properly confirmed
• in addition, the requestId changes, so the old code immediately becomes invalid

In short: an approval loop.

regal minnowBOT May 12, 2026, 4:06 PM

#

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

leaden egretBOT May 12, 2026, 4:07 PM

#

This sounds like the device/operator token is missing the scope needed to approve the next request — so the client is asking for pairing, but the approval path is also coming through that same unpaired/under-scoped client. Annoying loop, but usually fixable.

First: what version are you on?

openclaw --version

Then try the approval directly on the VPS over SSH, not through the remote client/UI that is saying pairing required:

openclaw gateway status
openclaw devices list
openclaw devices approve --latest   # preview only
openclaw devices list               # get the current requestId
openclaw devices approve <current-requestId>

#

Important details:

Use the current requestId from devices list; old IDs are invalid once the device retries with changed role/scopes/key.
If you’ve been passing --url, don’t for this local-on-VPS approval path unless you also pass the correct --token/--password. The devices docs note that explicit --url disables fallback to configured/env credentials.
If this is a scope upgrade, devices list should show requested vs approved scopes; approve the newest pending request.

If the loop persists after approving from SSH, do a full VPS reboot once, not just a gateway restart. We’ve seen sticky 1008 pairing required states on VPS setups clear only after a full machine reboot.

For Deepgram itself, the relevant config is:

{
  tools: {
    media: {
      audio: {
        enabled: true,
        models: [{ provider: "deepgram", model: "nova-3" }],

#

      },
    },
  },
}

and the env needs:

DEEPGRAM_API_KEY=dg_...

Docs: https://docs.openclaw.ai/cli/devices and https://docs.openclaw.ai/providers/deepgram

If you paste the output of openclaw --version plus openclaw devices list with secrets removed, we can tell whether it’s a normal scope-upgrade request or a token drift problem.

potent lintel May 13, 2026, 3:39 PM

#

OpenClaw 2026.4.12 (1c0672b)

Direct scope access failed; using local fallback.
Pending (1)

│ Request │ Device │ Role │ Scopes │ IP │ Age │ Flags │

│ xxx │ Telegram Native │ operator │ operator.admin, operator.approvals, operator.read, operator.write, operator.pairing, operator. │ │ just now │ repair │
│ │ Approvals (default) │ │ talk.secrets │ │ │ │

Paired (2)

│ Device │ Roles │ Scopes │ Tokens │ IP │

│ agent │ operator │ operator.read │ operator │ │
│ xxx │ operator │ operator.admin, operator.read, operator.write, operator.approvals, operator.pairing │ operator │ │

leaden egretBOT May 13, 2026, 3:40 PM

#

That output is a pending scope upgrade/repair for your existing Telegram Native device, not a lost pairing.

The important bit: the paired device already has operator scopes, but it’s now requesting an updated contract that includes the extra secret/talk scope (talk.secrets / likely operator.talk.secrets, depending on display wrapping). The repair flag means OpenClaw thinks this is a recovery/upgrade path.

If you recognize that device and you’re intentionally reconnecting Telegram, do:

openclaw devices list
openclaw devices approve <exact-request-id>

Use the current request id from devices list right before approving — don’t rely on an old copied one. After approval, retry/restart the Telegram connection.

If you don’t recognize it, reject it instead:

#

openclaw devices reject <request-id>

Docs: https://docs.openclaw.ai/cli/devices

potent lintel May 13, 2026, 3:49 PM

#

Wenn ich versuche openclaw devices approve <exact-request-id>, kommt: gateway connect failed: GatewayClientRequestError: pairing required

leaden egretBOT May 13, 2026, 3:50 PM

#

Dann versucht dein approve gerade selbst mit einer Identität zu verbinden, die noch keine Pairing-Berechtigung hat. Du brauchst fürs Approven entweder lokalen Fallback auf dem Gateway-Host oder Shared-Secret-Auth — nicht den pending Telegram-Device-Token.

Probier das so:

Auf dem Rechner/VPS, auf dem der Gateway läuft:

openclaw devices list
openclaw devices approve <request-id>

Wichtig: kein --url mitschicken. Wenn du --url setzt, fällt die CLI laut Docs nicht auf lokale/config Credentials zurück.

Falls du remote zugreifst oder trotzdem pairing required bekommst, nutze den Gateway-Token explizit — aber bitte nicht hier posten:

#

TOKEN="$(openclaw config get gateway.auth.token)"
openclaw devices approve <request-id> --url ws://127.0.0.1:18789 --token "$TOKEN"

Wenn dein Gateway auf einer anderen URL/Port läuft, nimm die URL aus:

openclaw gateway status

Wenn danach noch derselbe Fehler kommt, poste bitte nur die Ausgabe von:

openclaw gateway status
openclaw devices list

#

Tokens/Passwords vorher rauslassen/redacten. 🦞

Docs: https://docs.openclaw.ai/cli/devices

potent lintel May 13, 2026, 3:52 PM

#

Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-05-13.log

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (Failed to connect to system scope bus via machine transport: Protocol error
Failed to get properties: Transport endpoint is not connected)
RPC probe: ok

Troubles: run openclaw status

Was soll ich jetzt konkret machen?

leaden egretBOT May 13, 2026, 3:53 PM

#

Okay, dein Gateway läuft und RPC ist erreichbar — systemd (disabled) ist hier erstmal nicht das Problem.

Mach jetzt bitte genau diese Schritte auf demselben Rechner, auf dem der Gateway läuft:

openclaw devices approve --latest

Das approved noch nicht, sondern zeigt dir die neueste Pending-Anfrage + den exakten Approve-Befehl. Kopier dann genau den Befehl, den OpenClaw ausgibt, z.B.:

openclaw devices approve <request-id>

Wichtig: kein --url, kein alter kopierter Request, und keine Tokens hier posten.

Falls wieder pairing required kommt, probier direkt danach einmal ohne evtl. störende Env-Credentials:

#

env -u OPENCLAW_GATEWAY_URL -u OPENCLAW_GATEWAY_TOKEN -u OPENCLAW_DEVICE_TOKEN openclaw devices approve <request-id>

Wenn das auch scheitert, dann bitte:

openclaw doctor
openclaw devices list

und die Ausgabe posten. Dann sehen wir, ob das ein Scope-Upgrade ist, das der lokale Fallback nicht sauber approved, oder ob ein stale Device-Token dazwischenfunkt.

potent lintel May 13, 2026, 4:24 PM

#

Welche Ausgaben brauchst du konkret?

leaden egretBOT May 13, 2026, 4:24 PM

#

Am besten diese 4 Blöcke, in der Reihenfolge — bitte Tokens/Passwords/Secrets schwärzen:

openclaw devices approve --latest

Dann den dort vorgeschlagenen exakten Approve-Befehl ausführen und Ausgabe posten:

openclaw devices approve <request-id>

Falls das pairing required zeigt, direkt danach:

env | grep -E 'OPENCLAW_(GATEWAY|DEVICE|AUTH|TOKEN|URL)'

#OpenClaw connection Deepgramm