Support 24/7
Client areaGet started
Shared hostingManaged WordPressReseller hostingOpenClaw hostingVPS hostingDedicated serversManaged serversAbout usHow we compareRegionsKnowledge baseSupportDomainsSSLBlogClient area
OpenClaw hosting
Knowledge base / OpenClaw hosting

First login: the gateway token and approving your devices

Where the token lives, why a new device has to be approved, and how to rotate or revoke a token when a laptop goes missing.

Last updated: September 16, 2026

Your container arrives with OpenClaw already installed and the gateway running, so the first thing you do is not an install — it is proving who you are.

  1. 1Open the control UIThe gateway listens on port 18789. On a managed container you reach it through the URL in the panel.
  2. 2Approve the deviceEvery new device ID has to be approved before it can talk to the gateway.
  3. 3Pair a phoneMobile companion apps connect as nodes over the same WebSocket.
  4. 4Rotate or revoke when something changesTwo operations, both requiring the operator.pairing scope.
First login, in order. Run `openclaw doctor --fix` at the end — it validates the configuration and repairs what it safely can.

1. Open the control UI

The gateway listens on port 18789. On a managed container you reach it through the URL in your panel rather than over the open internet; openclaw dashboard opens the same interface when you have shell access.

If the dashboard asks for credentials, it is running in shared-secret mode (gateway.auth.mode: "token", the default) and wants the value of gateway.auth.token from your configuration at ~/.openclaw/openclaw.json.

On inSave containers the gateway is not exposed to the public internet, the token is generated per container at provisioning, and rotation is handled for you — you never paste a shared secret into a chat window to get started.

2. Approve the device

Every new device ID has to be approved before it can talk to the gateway. Auto-approval only covers direct loopback connections: a connection from your phone, your laptop, or even the same host over Tailscale or the LAN counts as remote and waits for approval.

That is the behaviour you want. It means somebody who learns your gateway address still cannot attach a device without your say-so.

After approval the gateway issues a device token scoped to that device and role and returns it in hello-ok.auth.deviceToken. The client stores it and uses it for later connects — you do not retype the shared secret.

3. Pair a phone

Mobile companion apps connect as nodes over the same WebSocket. Generate a setup code in the control UI — the API behind the button is device.pair.setupCode, which returns a QR code — then scan it from the app. device.pair.list shows what is pending and what is already approved.

4. Rotate or revoke when something changes

Two operations, both requiring the operator.pairing scope:

  • device.token.rotate — issues a replacement token for a device you still control. Use it on a schedule, and after anyone who had access leaves.
  • device.token.revoke — kills a token outright. Use it the moment a laptop or phone goes missing.

A rotation cannot grant a role that the original pairing approval did not include, so a compromised node cannot promote itself.

What to check before you move on

openclaw doctor --fix     # validates the configuration and repairs what it safely can

You should see the gateway bound as expected, your approved devices listed, and no warning about an open bind. If doctor reports the gateway listening on a non-loopback address without auth, stop and fix that before connecting a channel.