openclaw - 💡(How to fix) Fix [bug]：Gateway pairing failure on Trim OS / TerraMaster NAS: WebSocket closes with code 1002 during device proof response

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Subject: Gateway pairing failure on Trim OS / TerraMaster NAS: WebSocket closes with code 1002 during device proof response

Environment:

• Platform: Trim OS / TerraMaster NAS
• Package: trim.openclaw
• OpenClaw version: 2026.3.13
• Gateway process: openclaw-gateway
• Gateway is managed by the Trim OS app service / init system
• Gateway port observed: 42919
• Config path: /vol1/@apphome/trim.openclaw/data/home/.openclaw/openclaw.json
• Device identity path: /vol1/@apphome/trim.openclaw/data/home/.openclaw/identity/device.json

Issue summary: The OpenClaw Gateway starts successfully, but CLI / cron / child-agent clients cannot complete Gateway Pairing. The WebSocket connection itself works and the client receives the pairing challenge/nonce from the Gateway. However, after sending the signed proof response, the Gateway closes the WebSocket connection with close code 1002.

Observed behavior:

1. Client connects to the Gateway WebSocket successfully.
2. Gateway sends a pairing challenge containing nonce/timestamp data.
3. Client can read the local device identity from: ~/.openclaw/identity/device.json
4. Client can sign the challenge using the device private key.
5. When the proof response is sent back to Gateway, Gateway rejects it and closes the WebSocket with code 1002.

This suggests that TCP/WebSocket connectivity is fine, and the device private key is usable, but the pairing proof payload format expected by Gateway does not match what the CLI/client is generating.

Suspected root cause: Gateway appears to expect a specific v3 pairing proof envelope, possibly including fields such as:

• platform
• deviceFamily
• deviceId
• client metadata
• scopes
• nonce
• timestamp
• signature

However, the CLI/client appears to be signing or sending an incompatible payload format. Signing only the nonce or nonce:timestamp is not accepted. Because the proof format appears to be internal/minified, it is difficult to reproduce or debug manually.

Additional Trim OS integration issue: On Trim OS, openclaw-gateway is managed as a supervised system process. Killing the openclaw-gateway process causes it to be restarted automatically with a new PID.

Also, every time the Gateway is started through the Trim OS / OpenClaw app management layer, the config file is regenerated:

/vol1/@apphome/trim.openclaw/data/home/.openclaw/openclaw.json

The generated config writes gateway.auth back into the config even after it is manually removed.

Example: "gateway": { "controlUi": { "allowInsecureAuth": true, "dangerouslyDisableDeviceAuth": true }, "auth": { "token": "REDACTED" } }

Because gateway.auth is restored automatically, manually setting:

• gateway.controlUi.allowInsecureAuth = true
• gateway.controlUi.dangerouslyDisableDeviceAuth = true
• removing gateway.auth

does not persist after Gateway restart.

Impact:

• CLI tools cannot authenticate with the Gateway.
• Cron / automation jobs cannot connect to Gateway.
• Child agents or local clients requiring Gateway WebSocket access are blocked by pairing.
• It is not possible to reliably bypass pairing through openclaw.json because the Trim OS app manager rewrites gateway.auth on restart.

Expected behavior: One of the following should work:

1. The official CLI should successfully complete the Gateway Pairing v3 handshake with the current Gateway version.

2. There should be a documented command to pair a local CLI/device with the Gateway, for example: openclaw device pair openclaw gateway pair openclaw auth pair

3. The Gateway should provide a documented proof payload format for device pairing.

4. The Trim OS app manager should respect user config and should not forcibly rewrite gateway.auth if the user has explicitly disabled device auth / insecure auth.

5. There should be a supported configuration option to disable Gateway device pairing for loopback-only deployments.

Relevant observations:

• Gateway itself starts normally.
• WebSocket connection is established.
• Pairing challenge is received.
• Device private key signing works.
• Failure happens only when sending the proof response.
• WebSocket close code: 1002
• openclaw-gateway process is supervised and restarts automatically.
• openclaw.json is regenerated on Gateway restart and gateway.auth is restored.

Request: Could you please confirm the correct Gateway Pairing v3 proof payload format, or provide an updated CLI / pairing command that is compatible with OpenClaw 2026.3.13 on Trim OS?

It would also be helpful if the Trim OS integration could expose a supported way to disable Gateway auth for loopback-only local deployments, or stop rewriting gateway.auth when the user has explicitly configured insecure/device-auth-disabled mode.

Please let me know if you need logs, config snippets with secrets redacted, or a minimal reproduction.

Steps to reproduce

Reproduction steps:

1. Start OpenClaw Gateway from the Trim OS app panel.
2. Confirm openclaw-gateway is running and listening on port 42919.
3. Connect a local CLI/client to the Gateway WebSocket.
4. Observe that Gateway sends a pairing challenge.
5. Sign the challenge using ~/.openclaw/identity/device.json.
6. Send the proof response.
7. Gateway closes the connection with WebSocket code 1002.
8. Remove gateway.auth from openclaw.json and restart Gateway.
9. Observe that Trim OS app manager regenerates openclaw.json and writes gateway.auth back.

Expected behavior

OpenClaw CLI / cron / local child-agent clients should be able to connect to the local OpenClaw Gateway and complete the Gateway Pairing process successfully.

For a loopback-only deployment, if the user explicitly enables allowInsecureAuth and dangerouslyDisableDeviceAuth, the Gateway should either bypass device pairing or provide a documented and reliable pairing command.

The Trim OS OpenClaw app manager should also respect the user’s gateway configuration and should not regenerate openclaw.json in a way that forcibly restores gateway.auth after it has been removed or disabled by the user.

Actual behavior

The Gateway starts successfully and WebSocket connectivity works. The client can connect to the Gateway and receive the pairing challenge / nonce.

However, after signing the challenge using the local device identity from ~/.openclaw/identity/device.json and sending the proof response back, the Gateway rejects the response and closes the WebSocket connection with close code 1002.

This suggests that the TCP/WebSocket connection is fine and the device private key is usable, but the pairing proof payload format expected by the Gateway does not match what the CLI/client is sending.

Additionally, on Trim OS, openclaw-gateway is managed as a supervised system process. Killing the process causes it to restart automatically with a new PID. Each time the Gateway is restarted through the Trim OS / OpenClaw app management layer, openclaw.json is regenerated and gateway.auth is written back into the configuration.

Because of this, manually removing gateway.auth or enabling allowInsecureAuth / dangerouslyDisableDeviceAuth does not provide a persistent workaround.

OpenClaw version

2026.3.13

Operating system

Trim OS / TerraMaster NAS

Install method

No response

Model

deepseekv4 pro

Provider / routing chain

Local client / CLI / cron / child-agent → local OpenClaw Gateway WebSocket → openclaw-gateway managed by Trim OS app service / init system → OpenClaw model provider routing Configured model providers include: - DeepSeek provider - Google / Gemini provider The issue occurs before model routing completes. It happens during the Gateway Pairing / WebSocket authentication stage, before the request can be reliably routed to the configured model provider.

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response