[Bug]: Tray regenerates device-key-ed25519.json on every reboot, requiring re-pairing each time

[FYFran]

[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

1. Pair the Windows Node through the Tray app
2. Reboot the computer
3. 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.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 20, 2026, 2:22 AM ET / 06:22 UTC.

Summary
This should remain open: repeated device-identity rotation would break the established pairing contract, but the current report has not yet been reproduced against current main and the nearby closed torn-write report does not establish the same trigger.

Reproducibility: no. The report supplies a credible Windows reboot sequence and logs from v0.6.12, but there is not yet a verified current-main reproduction showing the key file changes across a controlled restart.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
A maintainer should first confirm the exact current-main reboot-time mutation or load failure because this path handles persistent device credentials and overlaps only partially with the prior torn-write report.

Security
Needs attention: The report concerns persistence of a device private-key identity and repeated authentication re-enrollment; the exact current-main failure path needs confirmation before a security-sensitive repair is chosen.

Review details

Best possible solution:

Add a focused Windows regression that pairs once, restarts the Tray process, and proves the key fingerprint and device ID remain stable; then route every identity-file mutation and recovery decision through one atomic, non-destructive persistence contract.

Do we have a high-confidence way to reproduce the issue?

No. The report supplies a credible Windows reboot sequence and logs from v0.6.12, but there is not yet a verified current-main reproduction showing the key file changes across a controlled restart.

Is this the best way to solve the issue?

Unclear. Preserving a stable per-gateway identity is the right contract, but current-main tracing and a Windows restart proof are needed before selecting whether the fault is startup loading, token clearing, rollback restore, or corrupted-file recovery.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A token-clear or startup path that overwrites or fails to load the per-gateway private key would create recurring re-pairing, stale gateway records, and avoidable authentication disruption for existing paired nodes.
• The report and the related torn-write analysis point to different triggers, so changing a writer without a current Windows reboot proof could repair the wrong path or miss a second identity-rotation route.

Codex review notes: model internal, reasoning high; reviewed against bd6c4bf8e575.

Label changes

Label changes:

• add P1: Repeated re-pairing after every reboot disrupts a real gateway/node workflow for affected Windows users.
• add impact:security: The reported overwritten artifact is the persisted Ed25519 device private-key identity used for pairing.
• add impact:auth-provider: The observable failure is gateway device authentication no longer recognizing the previously paired node.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: Repeated re-pairing after every reboot disrupts a real gateway/node workflow for affected Windows users.
• impact:security: The reported overwritten artifact is the persisted Ed25519 device private-key identity used for pairing.
• impact:auth-provider: The observable failure is gateway device authentication no longer recognizing the previously paired node.

Evidence reviewed

Security concerns:

• [medium] Verify device-key persistence before changing authentication storage
  A per-boot key replacement would rotate the device authentication identity and cause new enrollment requests; confirm the writer, loader, and corrupted-file recovery paths on current main before changing persisted credential handling.
  Confidence: 0.74

What I checked:

• Reported current release behavior: The report provides a concrete Windows reboot sequence on Tray v0.6.12, stable gateway directory evidence, changing node IDs, and redacted handshake output showing a fresh role-upgrade pairing flow on each boot. (4166e0fd63f8)
• Documented persistence contract: The setup documentation describes per-gateway device identity files under the Tray data directory as persistent user data, which supports the expected stable-identity behavior rather than intentional per-boot regeneration. (docs/SETUP.md)
• Related but unproven shared failure mode: Closed issue [Bug]: device-key-ed25519.json rewritten non-atomically in ClearStoredTokens → torn write silently rotates device identity #888 identifies a separate source-derived path where an interrupted token clear can leave an invalid key file and cause a later identity rotation. It overlaps in outcome but does not prove the reported every-reboot trigger. (src/OpenClaw.Connection/DeviceIdentityStore.cs:60, 87dc3dc79d7c)

Likely related people:

• shanselman: Public repository release history shows repeated ownership of Windows Tray, setup, connection, and diagnostic work; direct line-level provenance for this exact current-main path still needs a local history pass. (role: recent repository contributor; confidence: low; commits: 4166e0fd63f8; files: docs/SETUP.md, src/OpenClaw.Connection/DeviceIdentityStore.cs, src/OpenClaw.Shared/DeviceIdentity.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[shanselman]

Very odd, I don't see this on my systems, but this "→ error: "pairing required: device is asking for a higher role than currently approved" is interesting...taking a look...

[shanselman]

GitHub Copilot maintainer-assistant investigation — automated, not written personally by Scott.

@FYFran, thank you for the unusually detailed report. We traced the exact v0.6.12 tag and current main rather than assuming the filesystem timestamp proves rotation.

Current finding: this is not yet a demonstrated recent regression, but the report exposes a real longstanding fail-open hazard. DeviceIdentity.LoadExisting() has behaved this way since the identity implementation was introduced in February: if an existing device-key-ed25519.json is unreadable, malformed, missing PrivateKeyBase64, or throws during key reconstruction, it logs Failed to load device key... and immediately calls GenerateNew(), overwriting the existing identity. That behavior is identical in v0.6.12 and current main. It would work indefinitely on machines where the file is readable—as it does on our current systems—but a transient boot-time ACL/file-access/parse failure can silently rotate identity.

One important evidence nuance: token persistence writes through a temporary file plus File.Move(..., overwrite: true). On NTFS that replacement can give the JSON file a new filesystem creation timestamp even when PrivateKeyBase64, DeviceId, and the keypair were preserved. So the timestamp alone cannot distinguish token refresh from key rotation. The changing node IDs are stronger evidence because the Windows node sends its cryptographic DeviceId as
odeId, but we need to confirm the JSON's non-secret identity fields changed too.

Could you please capture the following around one reboot, without sharing PrivateKeyBase64, device tokens, gateway tokens, or other secrets?

1. The JSON DeviceId and numeric CreatedAt values before and after reboot.
2. Startup log lines containing Loaded Ed25519 device identity, Failed to load device key, Invalid device key file, or Generating new Ed25519 device keypair (with paths/usernames redacted).
3. Whether current main/a newer build reproduces, since v0.6.12 predates the July multi-gateway credential hardening.

If DeviceId/JSON CreatedAt change and the failure/generation lines appear, the repair should be non-destructive: an existing identity that cannot be loaded must never be overwritten automatically. It should fail closed (with a typed diagnostic/retry or explicit reset path), while generation remains allowed only when the file is genuinely absent. We should also add a full process-restart regression proving the identity remains stable; the existing same-directory reload test does not cover this boot-time failure mode.

[askforfly]

I have the same problem, when I restart the gateway , the openclaw companion needs to re-paring.