Summary

On macOS, device-auth.json tokens are reset to {} on every CLI invocation, causing all commands (including oc tui, openclaw devices list, openclaw gateway status) to fail with unauthorized: device token mismatch (rotate/reissue device token). The gateway is healthy and the device is correctly paired server-side (devices/paired.json has the token), but the client-side auth file never retains the token.

This is a catch-22: you can't run openclaw devices approve or openclaw devices rotate because those commands also require device-identity auth to connect to the gateway.

Steps to reproduce

1. Completely remove OpenClaw:

   launchctl bootout gui/501/ai.openclaw.gateway
   pkill -9 -f "openclaw"
   npm uninstall -g openclaw
   rm -rf ~/.openclaw /tmp/openclaw ~/Library/LaunchAgents/ai.openclaw.gateway.plist

2. Fresh install:

   npm install -g openclaw@2026.2.19
   openclaw onboard

3. Complete onboarding (gateway starts, Anthropic auth configured).

4. Verify gateway is running:

   openclaw gateway status
   # Shows: Runtime: running, RPC probe: ok (when using static token)

5. Attempt to connect:

   oc tui
   # FAILS: unauthorized: device token mismatch (rotate/reissue device token)

6. Inspect the files:

   cat ~/.openclaw/identity/device-auth.json
   # Shows: { "version": 1, "deviceId": "...", "tokens": {} }
   
   cat ~/.openclaw/devices/paired.json
   # Shows: device IS paired with a valid operator token

The token exists in paired.json (server-side) but device-auth.json (client-side) always has "tokens": {}.

Key observations

• Manually writing tokens to device-auth.json does not work. The CLI binary resets the file to "tokens": {} on every invocation before attempting to connect.
• The gateway itself is healthy. The static token auth path works perfectly — oc tui --token <gateway-auth-token> connects immediately.
• OPENCLAW_GATEWAY_TOKEN env var works as a workaround. Setting this env var makes all CLI commands use static token auth instead of device-identity auth.
• The bug survives full nuke-and-reinstall. Three complete wipe-and-reinstall cycles across three versions all produce the same result.
• Connecting via Control UI (browser) or --token flag DOES populate paired.json server-side, but the client-side device-auth.json is never written.
• openclaw gateway install --force may be involved. One of the early observations was that this command appeared to reset device-auth.json to empty tokens.

Expected behavior

Expected behavior

After openclaw onboard completes and the gateway is running, the CLI should be able to connect using device-identity auth. device-auth.json should contain the operator token matching the entry in devices/paired.json.

Actual behavior

Actual behavior

device-auth.json tokens are always {}. Every CLI command fails with:

gateway connect failed: Error: unauthorized: device token mismatch (rotate/reissue device token)
Gateway target: ws://127.0.0.1:18789
Source: local loopback

OpenClaw version

All exhibit identical behavior: - 2026.2.17 (beta channel) - 2026.2.19 (stable) - 2026.2.19-2 (stable)

Operating system

macOS 26.3

Install method

npm install -g openclaw

Logs, screenshots, and evidence

Impact and severity

Severity: High / P1
This is a complete authentication failure that makes the CLI unusable out of the box on macOS. Every fresh install is broken. The impact:

• 100% of macOS fresh installs are affected — tested across three versions (2.17, 2.19, 2.19-2), all identical behavior
• All CLI commands are blocked — not just oc tui, but openclaw devices list, openclaw status, openclaw doctor, everything that connects to the gateway
• Self-healing commands are also broken — openclaw devices approve, openclaw devices rotate can't run because they need the same auth that's broken. It's a catch-22 with no CLI-based escape.
• Onboarding completes without error but leaves the system in a broken state — there's no indication to the user that anything went wrong
• The workaround is non-obvious — setting OPENCLAW_GATEWAY_TOKEN env var requires understanding the static token auth path, which isn't documented as a fallback for device-identity failures

It's not critical/P0 because the workaround exists and data loss isn't involved. But for any new macOS user who installs OpenClaw and tries to use it, the first experience is a wall of device token mismatch errors with no clear path forward.

Additional information

Workaround

Store the static gateway auth token from openclaw.json → gateway.auth.token as an environment variable:

export OPENCLAW_GATEWAY_TOKEN="<your-gateway-auth-token>"

All CLI commands then use static token auth and bypass the broken device-identity layer.

Not the same as #18475 / #18498

Those issues are about the gateway status probe not inheriting systemd EnvironmentFile vars on Linux. This bug is macOS-specific, affects ALL CLI commands (not just the probe), and is caused by device-auth.json tokens never being persisted — not by environment variable mismatch.