lavish tulip
I am trying to run a openclaw gateway on docker but having issues with approving my local device chat interface via the browser, since the CLI only gets operator.pairing scope which is not enough to approve the chat interface. I have to resort to HACKING the paired.json file in the same way it seems the CLI binary resolves it, by falling back to the local fallback trigger.
Is there no way for me to address this without having to resort to directly writing the paired.json file on the runtime directory?
=====
The compose exec approach does run the same CLI binary inside the container. The difference is what happens at the network layer before the CLI even gets to run the approve command.
Inside the container (compose exec):
CLI → ws://127.0.0.1:18789 → gateway sees 127.0.0.1 (loopback)
→ isCliContainerLocalEquivalent() = true
→ shouldAllowSilentLocalPairing() = true
→ gateway silently auto-pairs the CLI with limited "operator.pairing" scopes
→ connection SUCCEEDS (no error)
→ CLI sends device.pair.approve RPC
→ gateway rejects: "missing scope: operator.admin"
→ this is NOT a "pairing required" error → no local fallback → hard failure
From the host (host-installed CLI):
CLI → ws://127.0.0.1:19789 → Docker NAT → gateway sees 172.17.0.1 (bridge IP)
→ isCliContainerLocalEquivalent() = false (not loopback)
→ shouldAllowSilentLocalPairing() = false
→ gateway rejects: "device pairing required"
→ this IS a "pairing required" error → local fallback triggers
→ CLI writes device files directly with callerScopes: ["operator.admin"]
→ success
The irony is that auto-pairing is a convenience feature — it lets CLI tools inside the container work without manual approval for routine operations. But it backfires for devices approve because the auto-paired CLI gets scopes that are too limited to approve other devices, and the error it gets ("missing scope") doesn't trigger the fallback path that would bypass it.