[Bug]: Windows Tray regenerates device identity on every reboot, requiring re-pairing each time
Summary
After every system reboot, the OpenClaw Windows Tray (v0.6.12) generates a new device keypair instead of reusing the persisted one in AppData\Roaming\OpenClawTray\gateways\{id}\device-key-ed25519.json. This causes a new deviceId, which the gateway doesn't recognize → triggers a re-pairing flow every single boot.
Environment
- OpenClaw Gateway: v2026.7.1-2
- OpenClaw Tray: v0.6.12 (WinUI 3 companion app)
- OS: Windows 11 (Build 26200)
- Setup: Gateway + Node on same machine (localhost,
ws://127.0.0.1:18789)
- Gateway mode: local, token auth
Steps to Reproduce
- Pair the Windows Node through the Tray app
- Reboot the computer
- After reboot, check
openclaw nodes list
Actual Behavior
Every reboot creates a brand new node entry with a different nodeId:
# Reboot 1: nodeId = f6f52b38...
# Reboot 2: nodeId = 43ea1d7e...
# Reboot 3: nodeId = f1985d41...
# Reboot 4: nodeId = dcafbd90...
# Reboot 5: nodeId = 1ebcfe09...
Evidence from Tray logs showing the handshake flow on each boot:
[HANDSHAKE] isBootstrap=False, hasNodeDeviceToken=[REDACTED]
→ device.pair.requested (reason: "role-upgrade")
→ error: "pairing required: device is asking for a higher role than currently approved"
→ node.pair.requested
→ auto-approve cron approves → Paired!
The device-key-ed25519.json file is overwritten with a brand new keypair on each startup (file creation time matches boot time).
Meanwhile, C:\Users\{user}\.openclaw\nodes\paired.json accumulates stale entries — one per reboot.
Expected Behavior
- Tray should load the existing
device-key-ed25519.json on startup
- Same
deviceId should persist across reboots
- Gateway should recognize the device and skip re-pairing
Root Cause Analysis
The Tray app appears to generate a new Ed25519 keypair on every startup instead of checking if device-key-ed25519.json already exists and loading it. The persistent file at AppData\Roaming\OpenClawTray\gateways\{gatewayId}\device-key-ed25519.json gets overwritten each time.
The auto-approve cron workaround handles the re-pairing automatically, so the node eventually works — but this creates unnecessary pairing entries, a ~60 second gap on boot, and is a fundamentally broken identity persistence model.
Additional Context
- macOS/Linux nodes don't have this issue — identity persists correctly
devices/paired.json on the gateway side also only retains the latest entry, suggesting the gateway side also doesn't handle device identity churn gracefully- The
gatewayId directory name (94356bcb-...) is stable across reboots, ruling out a directory path issue
Workaround
Set up an auto-approve cron that runs every 30 seconds to catch the pending pairing request. This masks the symptom but doesn't fix the root cause.
[Bug]: Windows Tray regenerates device identity on every reboot, requiring re-pairing each time
Summary
After every system reboot, the OpenClaw Windows Tray (v0.6.12) generates a new device keypair instead of reusing the persisted one in
AppData\Roaming\OpenClawTray\gateways\{id}\device-key-ed25519.json. This causes a newdeviceId, which the gateway doesn't recognize → triggers a re-pairing flow every single boot.Environment
ws://127.0.0.1:18789)Steps to Reproduce
openclaw nodes listActual Behavior
Every reboot creates a brand new node entry with a different
nodeId:Evidence from Tray logs showing the handshake flow on each boot:
The
device-key-ed25519.jsonfile is overwritten with a brand new keypair on each startup (file creation time matches boot time).Meanwhile,
C:\Users\{user}\.openclaw\nodes\paired.jsonaccumulates stale entries — one per reboot.Expected Behavior
device-key-ed25519.jsonon startupdeviceIdshould persist across rebootsRoot Cause Analysis
The Tray app appears to generate a new Ed25519 keypair on every startup instead of checking if
device-key-ed25519.jsonalready exists and loading it. The persistent file atAppData\Roaming\OpenClawTray\gateways\{gatewayId}\device-key-ed25519.jsongets overwritten each time.The auto-approve cron workaround handles the re-pairing automatically, so the node eventually works — but this creates unnecessary pairing entries, a ~60 second gap on boot, and is a fundamentally broken identity persistence model.
Additional Context
devices/paired.jsonon the gateway side also only retains the latest entry, suggesting the gateway side also doesn't handle device identity churn gracefullygatewayIddirectory name (94356bcb-...) is stable across reboots, ruling out a directory path issueWorkaround
Set up an auto-approve cron that runs every 30 seconds to catch the pending pairing request. This masks the symptom but doesn't fix the root cause.