[Repo Assist] fix: guard bootstrap prompt against already-configured workspaces

[github-actions]

🤖 This is an automated pull request from Repo Assist, an AI assistant for this repository.

Summary

Closes #729

OnboardingChatBootstrapper.BootstrapAsync() only checked HasInjectedFirstRunBootstrap before sending the first-run bootstrap prompt. This flag defaults to false and is only set to true after a successful first-run completion. On reinstall over an existing workspace — or after any settings migration that resets the flag — this caused the bootstrap ritual to fire against an already-configured workspace.

Root Cause

ShouldBootstrap() / BootstrapAsync() had a single guard:

if (settings.HasInjectedFirstRunBootstrap) return;

No check was made against the GatewayRegistry to determine whether usable credentials already exist.

Fix

Before sending the prompt, BootstrapAsync() now calls SetupExistingGatewayClassifier.HasAnyExistingGatewayConnection(registry, settings, dataPath). If the registry has any usable record (shared gateway token, bootstrap token, or per-gateway device key), the bootstrapper silently calls MarkBootstrapped() and exits — same end state as completing first-run normally, but without prompting the user.

ChatPage.xaml.cs passes registry: app.Registry to the call. The registry parameter is optional (= null), so callers that don't pass it continue to get the previous behavior unchanged.

Trade-offs

• SettingsManager.SettingsDirectoryPath is the static env-var path used for the dataPath argument in the guard. In tests this differs from the injected _settingsDirectory, but tests exercise the registry path (condition 1/2) which fires before the dataPath is needed, so all tests pass correctly.
• ShouldBootstrap() is dead code (never called) — left unchanged to avoid unrelated scope creep.

Changes

File	Change
src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs	Add using OpenClaw.Connection;, add optional GatewayRegistry? registry param to BootstrapAsync(), add existing-gateway guard
src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs	Extract app variable, pass registry: app.Registry to BootstrapAsync()
tests/OpenClaw.Tray.Tests/OnboardingChatBootstrapperTests.cs	Add 4 new tests for existing-gateway guard behavior

Test Status

• Build: ./build.ps1 requires Windows. Compilation validated via dotnet test /p:EnableWindowsTargeting=true on Linux CI.
• Tray tests: 996 passed (994 passed, 2 skipped, 0 failed) ✅ — includes 4 new tests for the guard
• Shared tests: 8 pre-existing failures (MxcPolicyBuilderTests, ExecApprovalV2NormalizationTests, McpHttpServerTests — Windows-specific, present on main before this change) ✅

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[clawsweeper]

Codex review: found issues before merge. Reviewed June 9, 2026, 9:52 PM ET / 01:52 UTC.

Summary
The PR adds a GatewayRegistry-aware guard to OnboardingChatBootstrapper.BootstrapAsync(), passes App.Registry from ChatPage, and adds bootstrapper tests around registry-token cases.

Reproducibility: yes. for the PR regression from source inspection: setup creates registry-backed credentials, and the added guard treats those credentials as a completed first-run state before sending the bootstrap message. I did not run a live Windows tray smoke because this is a read-only review.

Review metrics: 1 noteworthy metric.

• Touched surface: 2 production files, 1 test file. The change sits directly on first-run chat bootstrapping, so a small diff still affects onboarding state.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦪 silver shellfish
Result: blocked until real behavior proof is added.

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

Rank-up moves:

• Post redacted real behavior proof, such as a short desktop recording or logs, showing an already configured workspace skips the prompt and a fresh setup still receives it.
• Revise the guard and tests so a newly-created credentialed gateway does not consume the first-run bootstrap gate.

Proof guidance:

• [P1] Needs real behavior proof before merge: No after-fix real behavior proof is present; tests and reported CI output do not show the tray behavior in a real configured workspace or fresh setup. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Mantis proof suggestion
A desktop proof would materially help verify the visible tray/chat onboarding behavior across existing and fresh setup states. 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: verify a fresh configured gateway still receives the first-run bootstrap prompt while an already configured workspace skips it.

Risk before merge

• [P1] A normal fresh setup can already have a GatewayRecord with a bootstrap token or device identity by the time chat opens; this PR would mark HasInjectedFirstRunBootstrap true without sending the first-run prompt.
• [P1] The PR body reports unit-test output but does not include real app proof showing both the existing-workspace skip path and the fresh-setup prompt path.

Maintainer options:

1. Fix the first-run discriminator before merge (recommended)
   Change the guard so a newly-created setup gateway still receives the bootstrap prompt, while a prior configured workspace skips it, and add regression coverage for both states.
2. Pause this bot branch
   If the correct discriminator needs product input, leave the linked issue open and replace this branch with a narrower maintainer-approved patch later.

Next step before merge

• [P2] The PR needs contributor revision and real behavior proof rather than a ClawSweeper repair lane, because automation cannot supply the contributor’s tray/setup proof and the correct first-run discriminator may need maintainer review.

Security
Cleared: No concrete security or supply-chain regression was found in the diff; the blocker is onboarding state correctness.

Review findings

• [P1] Preserve bootstrap for fresh gateway setup — src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:55-56

Review details

Best possible solution:

Use a first-run discriminator that separates reinstall/already-configured workspaces from newly-created setup credentials, then prove both flows with focused tests and redacted real behavior evidence.

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

Yes for the PR regression from source inspection: setup creates registry-backed credentials, and the added guard treats those credentials as a completed first-run state before sending the bootstrap message. I did not run a live Windows tray smoke because this is a read-only review.

Is this the best way to solve the issue?

No, not as written. Registry credentials alone are not a safe proxy for an already-configured workspace because fresh setup uses the same credential surfaces before the first-run prompt has run.

Full review comments:

• [P1] Preserve bootstrap for fresh gateway setup — src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:55-56
  This guard treats any usable registry record as proof that the workspace is not first-run, then persists HasInjectedFirstRunBootstrap without sending the prompt. Fresh setup creates registry-backed credentials before chat is usable, so a normal new install can enter this branch and never receive the first-run bootstrap; add a discriminator and test for a freshly-created credentialed gateway that still sends the prompt.
  Confidence: 0.89

Overall correctness: patch is incorrect
Overall confidence: 0.89

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 0e61fa287afb.

Label changes

Label changes:

• add P1: As written, the PR can break the first-run onboarding prompt for new users after setup creates a usable gateway record.
• add merge-risk: 🚨 session-state: Merging can persist HasInjectedFirstRunBootstrap=true without creating the first-run agent/workspace state the flag is meant to represent.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No after-fix real behavior proof is present; tests and reported CI output do not show the tray behavior in a real configured workspace or fresh setup. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Label justifications:

• P1: As written, the PR can break the first-run onboarding prompt for new users after setup creates a usable gateway record.
• merge-risk: 🚨 session-state: Merging can persist HasInjectedFirstRunBootstrap=true without creating the first-run agent/workspace state the flag is meant to represent.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: No after-fix real behavior proof is present; tests and reported CI output do not show the tray behavior in a real configured workspace or fresh setup. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Current bootstrap behavior on main: Current main sends the first-run bootstrap whenever HasInjectedFirstRunBootstrap is false and the operator client is connected; there is no registry/workspace guard before SendChatMessageForRunAsync(Message). (src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:43, 0e61fa287afb)
• Classifier treats fresh setup credentials as an existing connection: HasAnyExistingGatewayConnection() returns true for any registry record with SharedGatewayToken, BootstrapToken, or a per-gateway device token, which are also normal credentials after setup creates a gateway record. (src/OpenClaw.Tray.WinUI/Services/SetupExistingGatewayClassifier.cs:49, 0e61fa287afb)
• Onboarding docs show setup creates registry credentials: The onboarding docs say the first-launch setup flow installs a fresh local gateway, and credential storage documents that setup creates or updates GatewayRecord credentials before post-pairing identity is stored. (docs/ONBOARDING_WIZARD.md:7, 0e61fa287afb)
• PR diff marks the gate consumed on any usable registry connection: The proposed branch calls SetupExistingGatewayClassifier.HasAnyExistingGatewayConnection(...), then MarkBootstrapped(settings) and returns true before any prompt is sent. (src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:55, b466618aa202)
• PR fresh-gateway test uses an empty registry: The added test named for a new gateway only covers an empty registry, so it misses the realistic fresh setup state where chat is connected through a newly-created registry record with credentials. (tests/OpenClaw.Tray.Tests/OnboardingChatBootstrapperTests.cs, b466618aa202)
• Git history provenance: Blame and history for the bootstrapper, classifier, and ChatPage call site point to the v0.6.3 source import/localization commit, with later ChatPage maintenance nearby. (src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:1, 85445c78066b)

Likely related people:

• Christine Yan: Current blame for the bootstrapper, classifier, registry, and ChatPage call site points to the v0.6.3 source import/localization commit. (role: introduced behavior; confidence: medium; commits: 85445c78066b, e0a4b7c7c28d; files: src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs, src/OpenClaw.Tray.WinUI/Services/SetupExistingGatewayClassifier.cs, src/OpenClaw.Connection/GatewayRegistry.cs)
• Régis Brid: Recent commits touched the ChatPage waiting/navigation area that invokes the bootstrapper. (role: recent adjacent contributor; confidence: medium; commits: 753828f63e96, 6623cb8410a4; files: src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs)
• Scott Hanselman: Recent hardening touched the onboarding bootstrapper test file, though not the product logic itself. (role: recent test-area contributor; confidence: low; commits: d23f8ca50013; files: tests/OpenClaw.Tray.Tests/OnboardingChatBootstrapperTests.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.