fix(pairing): clarify reconnect and startup state

[vincentkoc]

Summary

• register setup-engine startup opt-in through a logon-triggered scheduled task, with the existing Run-key path as fallback
• carry operator/node credential source through connection snapshots so Connection UI can say when reconnect is using a paired device token
• suppress placeholder 1.0.0 app-version display for offline orphan paired-node rows, while preserving matched/online versions

Validation

• git diff --check
• local .NET validation blocked on this mac shell: dotnet and pwsh are not installed/resolving, and ./build.ps1 is not directly executable here

Notes

• This follows up PR fix(node): reconnect and report app version after restart #613. The merged PR used GitHub's rebase merge path because repository settings reject merge commits; it was not squashed.

[clawsweeper]

Codex review: found issues before merge. Reviewed June 3, 2026, 1:37 AM ET / 05:37 UTC.

Summary
This PR adds credential-source fields to connection snapshots and Connection UI labels, switches startup opt-in to a scheduled-task-first path with Run-key fallback, unregisters the task during cleanup, and hides placeholder versions for offline orphan nodes.

Reproducibility: yes. for the review finding: source inspection shows the PR deletes the HKCU Run value after scheduled-task registration while current docs still tell users to verify or remove only that Run entry. I did not run a Windows logon smoke in this read-only review.

Review metrics: 2 noteworthy metrics.

• Files changed: 17 files, +360/-25. The patch spans connection state, setup, shared startup helpers, tray UI, and tests.
• Startup persistence paths: 3 production paths changed. Setup completion, tray settings, and uninstall cleanup now depend on scheduled-task handling.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🌊 off-meta tidepool
Patch quality: 🦐 gold shrimp
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Update autostart troubleshooting and uninstall docs for the scheduled-task path.
• [P2] Run the AGENTS-required build, shared tests, and tray tests on Windows.
• [P2] Add or link a Windows startup smoke showing task-backed launch and fallback/cleanup behavior.

Mantis proof suggestion
A Windows desktop proof would materially help review because the risky behavior is task-backed startup plus visible Connection settings labeling. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: on Windows, verify that Start with Windows creates the OpenClaw Companion scheduled task and Connection settings shows paired device-token reconnect labels.

Risk before merge

• [P2] Successful scheduled-task registration now removes the existing HKCU Run fallback, so a task-creation success that does not actually launch at next logon would silently break an existing startup opt-in.
• [P1] Current setup and uninstall docs still direct users to the HKCU Run value only, so task-backed startup diagnostics and manual cleanup would be misleading after merge.
• [P1] The PR body reports only git diff --check; the AGENTS-required build, shared tests, tray tests, and a Windows logon/reboot startup smoke are still not reported for the current head.

Maintainer options:

1. Align docs and prove the startup migration (recommended)
   Update troubleshooting/uninstall guidance for the OpenClaw Companion scheduled task and provide Windows build/test plus logon or reboot smoke evidence before merge.
2. Accept the scheduled-task cutover as-is
   Maintainers can merge with the compatibility risk if they are comfortable owning possible startup-support churn until docs and diagnostics catch up.
3. Pause the startup-persistence portion
   If scheduled-task behavior is not ready for release, split or defer that part and keep the credential-source/version display cleanup separate.

Next step before merge

• [P2] A maintainer should decide the scheduled-task migration and require docs plus Windows validation before merge.

Security
Cleared: No concrete security or supply-chain regression was found; the scheduled-task helper uses System32 schtasks.exe and does not broaden credential handling.

Review findings

• [P2] Update autostart docs for scheduled-task storage — src/OpenClaw.Tray.WinUI/Services/AutoStartManager.cs:39

Review details

Best possible solution:

Land this after maintainers accept the scheduled-task startup direction, docs/diagnostics cover both scheduled-task and Run-key paths, and Windows validation proves task-backed startup, fallback, cleanup, and the connection-label behavior.

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

Yes for the review finding: source inspection shows the PR deletes the HKCU Run value after scheduled-task registration while current docs still tell users to verify or remove only that Run entry. I did not run a Windows logon smoke in this read-only review.

Is this the best way to solve the issue?

Not yet. Scheduled-task-first startup may be the right direction, but the maintainable merge path is to align docs/diagnostics and validate the Windows startup behavior before removing the old fallback from successful opt-ins.

Full review comments:

• [P2] Update autostart docs for scheduled-task storage — src/OpenClaw.Tray.WinUI/Services/AutoStartManager.cs:39
  After successful task registration this deletes the HKCU Run value, but the current setup and uninstall docs still tell users to check or remove only HKCU\...\Run\OpenClawTray. Once startup is task-backed, those instructions give false diagnostics and can leave the scheduled task behind, so the PR should update the troubleshooting and cleanup guidance for the OpenClaw Companion scheduled task as well as the Run-key fallback.
  Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.82

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 53ff55aff974.

Label changes

Label changes:

• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external-contributor proof gate does not apply to this repository-member PR, but Windows startup proof is still a merge-readiness risk.
• remove status: 👀 ready for maintainer look: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: This is a normal-priority Windows startup and connection-observability change with limited but real compatibility risk.
• merge-risk: 🚨 compatibility: Merging changes persisted startup behavior from HKCU Run to a scheduled task and removes the Run-key fallback after successful task creation.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The external-contributor proof gate does not apply to this repository-member PR, but Windows startup proof is still a merge-readiness risk.

Evidence reviewed

What I checked:

• Repository policy applies: AGENTS.md requires build, shared tests, tray tests, and connection/onboarding guidance for changes in this area. (AGENTS.md:7, 53ff55aff974)
• Startup persistence changes from Run key to scheduled task: The tray settings path now registers a Windows startup task first and deletes the legacy Run-key value after successful task creation. (src/OpenClaw.Tray.WinUI/Services/AutoStartManager.cs:37, e365ba37e8b6)
• Scheduled task command details: The new shared helper creates an ONLOGON task named OpenClaw Companion via System32 schtasks.exe. (src/OpenClaw.Shared/WindowsStartupTaskRegistration.cs:24, e365ba37e8b6)
• Current troubleshooting docs still point only to the Run key: The published setup troubleshooting path still tells users to check HKCU Run for OpenClawTray, which will be absent after successful task-backed registration. (docs/SETUP.md:187, 53ff55aff974)
• Current uninstall docs still remove only the Run key: Manual uninstall guidance removes HKCU Run but does not mention the new OpenClaw Companion scheduled task. (docs/uninstall-portable.md:61, 53ff55aff974)
• Credential source is carried into connection UI planning: The PR stores operator/node credential source in the connection snapshot and renders paired device-token labels in active gateway detail lines. (src/OpenClaw.Tray.WinUI/Pages/ConnectionPagePlan.cs:561, e365ba37e8b6)

Likely related people:

• Vincent Koc: Recent merged history includes persisted node-token reconnect, app-version reporting, node bootstrap, and pairing fixes in the same behavior area. (role: recent pairing and node reconnect contributor; confidence: high; commits: ee8fd4ef4ff0, 66683a33e770, eb06fba21c44; files: src/OpenClaw.Connection/GatewayConnectionManager.cs, src/OpenClaw.Connection/ConnectionStateMachine.cs, src/OpenClaw.Shared/WindowsNodeClient.cs)
• Régis Brid: Blame on the current AutoStartManager, GatewayConnectionManager, and InstanceMerger baselines traces to the latest release commit before this PR. (role: current baseline contributor; confidence: medium; commits: 7d9152f427a3; files: src/OpenClaw.Tray.WinUI/Services/AutoStartManager.cs, src/OpenClaw.Connection/GatewayConnectionManager.cs, src/OpenClaw.Shared/InstanceMerger.cs)
• Ranjesh: Recent history touched ConnectionPage.xaml.cs, which this PR also changes for saved gateway auth-mode labeling. (role: recent Connection page contributor; confidence: medium; commits: f4d4793f744f; files: src/OpenClaw.Tray.WinUI/Pages/ConnectionPage.xaml.cs)
• Mike Harsh: Earlier connection-manager work added and unified node connection ownership paths that this PR continues to build on. (role: connection architecture contributor; confidence: medium; commits: d0e184bd29c8, 0816eb0eefc0, 7baeeaec1016; files: src/OpenClaw.Connection/GatewayConnectionManager.cs, src/OpenClaw.Tray.WinUI/App.xaml.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

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]

Thanks for the cleanup work here. I don't think this is safe to merge yet because the startup/scheduled-task behavior still needs author clarification and hardening before we can be confident it won't misreport or change autostart state incorrectly.

Could you please address the scheduled-task scope/enabled-state concerns directly — especially whether the task is per-user vs all-user, how the UI determines the true enabled state, and how reconnect/startup status behaves after upgrades or missing tasks? Once that's explicit in code/tests/proof, this can get another focused review.