Tray chat repeatedly triggers first-run bootstrap prompt for an already configured workspace

[sorry123luck]

Summary

The Windows Tray/Companion chat can repeatedly trigger the first-run bootstrap prompt even when OpenClaw has already been configured and the workspace already contains OpenClaw memory/configuration files.

This is risky because the generated first-run prompt asks the agent to start the initial setup ritual and modify files such as SOUL.md, even though the user is not in a first-run state anymore.

Environment

• OpenClaw Windows Companion: v2026.6.1
• Gateway: OpenClaw v2026.6.1, running locally in WSL
• Gateway URL: ws://127.0.0.1:18789
• Windows user: Administrator
• Existing workspace path shown by the UI: /home/administrator/.openclaw/workspace
• Existing files shown by the UI include:
  • AGENTS.md
  • SOUL.md
  • TOOLS.md
  • IDENTITY.md
  • USER.md
  • HEARTBEAT.md
  • MEMORY.md

What happened

After the Tray was already connected and chat was usable, the app still injected a first-run style user message:

Hi! I just installed OpenClaw and you're my brand-new agent. Please start the first-run ritual from BOOTSTRAP.md, ask one question at a time, and before we talk about WhatsApp/Telegram, visit soul.md with me to craft SOUL.md: ask what matters to me and how you should be. Then guide me through choosing how we should talk (web-only, WhatsApp, or Telegram).

This happened more than once from the Tray/chat flow. The user already had an OpenClaw workspace and existing configuration/memory files, so this should not have been treated as a brand-new installation.

Expected behavior

The first-run bootstrap prompt should only be injected for a true first-run/new-workspace state.

If the workspace already has OpenClaw state such as SOUL.md, AGENTS.md, MEMORY.md, existing sessions, or a previously configured Gateway, the Tray should not automatically send the bootstrap ritual prompt.

At minimum, the app should ask for explicit user confirmation before injecting a prompt that can cause the agent to rewrite workspace/personality/config files.

Actual behavior

The Tray/chat path can inject the first-run prompt even though:

• the Gateway is already connected,
• the chat is usable,
• the workspace already has OpenClaw configuration files,
• the user is not intentionally starting a first-run setup.

Why this matters

This can cause the agent to perform setup actions against an already configured workspace. For an existing user, that can overwrite or drift important files such as SOUL.md or other workspace instructions.

Related prior work

This may be adjacent to #457, which fixed a zero-state chat/session-key trap around fresh installs and main / agent:main:main session handling.

The remaining issue here appears to be that the first-run/onboarding trigger can still fire from the Tray/chat path even when the current workspace is not actually new.

Suggested fix

• Gate first-run prompt injection on a durable "first run completed" marker, not only on current UI/session state.
• Treat an existing configured workspace as not first-run.
• Do not auto-send the bootstrap prompt from the Tray mini chat unless the setup state is definitely fresh.
• If the state is ambiguous, show an explicit confirmation before sending the prompt.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 9, 2026, 1:41 AM ET / 05:41 UTC.

Summary
Keep open: current main still has a source-reproducible path where the legacy Tray/Hub chat readiness flow sends the first-run bootstrap message based only on a one-shot settings flag, with no durable existing-workspace or configured-gateway guard.

Reproducibility: yes. by source inspection: with a connected operator client and HasInjectedFirstRunBootstrap == false, ChatPage calls BootstrapAsync, which sends the first-run prompt without checking existing workspace files or configured gateway state. I did not run a live Windows tray repro in this read-only review.

Next step
This is a localized Tray/onboarding repair with clear source evidence and focused test targets.

Review details

Best possible solution:

Keep the post-onboarding hatching flow, but gate prompt injection on a durable fresh-setup signal or explicit confirmation and skip it when existing gateway/workspace state shows the user is already configured.

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

Yes by source inspection: with a connected operator client and HasInjectedFirstRunBootstrap == false, ChatPage calls BootstrapAsync, which sends the first-run prompt without checking existing workspace files or configured gateway state. I did not run a live Windows tray repro in this read-only review.

Is this the best way to solve the issue?

Yes, the requested guard is the right direction; the narrow maintainable fix is to move the bootstrap decision from a bare one-shot flag to a true fresh-setup/configured-workspace check while preserving the intended post-setup launch path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The repair needs to preserve the intentional post-setup chat handoff while preventing ordinary chat opens or upgraded configured workspaces from sending the first-run prompt.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 71d249711d63.

Label changes

Label changes:

• add P2: This is a normal-priority Tray onboarding bug with meaningful but bounded risk to configured users.
• add impact:data-loss: The reported prompt can cause an agent to rewrite existing workspace/personality/configuration files such as SOUL.md.
• add impact:session-state: The bug is incorrect first-run/session setup state detection for an already configured workspace.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a normal-priority Tray onboarding bug with meaningful but bounded risk to configured users.
• impact:data-loss: The reported prompt can cause an agent to rewrite existing workspace/personality/configuration files such as SOUL.md.
• impact:session-state: The bug is incorrect first-run/session setup state detection for an already configured workspace.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Bootstrap prompt is hard-coded behind only the one-shot flag: OnboardingChatBootstrapper.Message contains the reported first-run prompt, and ShouldBootstrap returns true whenever HasInjectedFirstRunBootstrap is false. (src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:14, 71d249711d63)
• Chat readiness calls the bootstrapper unconditionally for that surface: After operator handshake and chat HTTP probing, ChatPage calls OnboardingChatBootstrapper.BootstrapAsync without checking whether the workspace already has OpenClaw files or prior setup state. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:500, 71d249711d63)
• Default settings make upgraded/configured users eligible for injection: HasInjectedFirstRunBootstrap defaults to false, so a configured workspace whose settings lack the new marker can still satisfy the current bootstrap gate. (src/OpenClaw.Tray.WinUI/Services/SettingsManager.cs:220, 71d249711d63)
• Existing tests do not cover configured-workspace suppression: The bootstrapper tests cover send-on-completion, synchronous completion, send failure, and timeout, but not a workspace/gateway-state guard that would block injection for existing users. (tests/OpenClaw.Tray.Tests/OnboardingChatBootstrapperTests.cs:23, 71d249711d63)
• Onboarding docs define the expected configured-user boundary: The onboarding wizard docs say first launch setup appears only when there is no usable saved gateway connection, which supports treating configured state as non-first-run. (docs/ONBOARDING_WIZARD.md:7, 71d249711d63)
• History points to the post-wizard chat handoff as the feature origin: fd8ff7d introduced the bootstrapper, ChatPage handoff, and tests for the post-wizard chat flow now implicated by this report. (src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs:14, fd8ff7dad9d4)

Likely related people:

• Mike Harsh: Introduced the post-wizard chat handoff/bootstrapper in fd8ff7d and later worked on V2 setup gating in 5831544. (role: introduced behavior and setup-flow contributor; confidence: high; commits: fd8ff7dad9d4, 58315446796e, 7f49beb0f571; files: src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs, src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs, src/OpenClaw.Tray.WinUI/Services/StartupSetupState.cs)
• Scott Hanselman: Recently touched ChatPage, StartupSetupState, and bootstrapper tests in the Slopwatch hardening pass, so may know the current guard expectations. (role: recent area contributor; confidence: medium; commits: d23f8ca50013; files: src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs, src/OpenClaw.Tray.WinUI/Services/StartupSetupState.cs, tests/OpenClaw.Tray.Tests/OnboardingChatBootstrapperTests.cs)
• Christine Yan: The current release-grafted blame for the involved files points through the v0.6.3 localization/code-behind commit, though earlier history shows the behavior was introduced before that. (role: recent release/localization contributor; confidence: low; commits: 85445c78066b; files: src/OpenClaw.Tray.WinUI/Services/OnboardingChatBootstrapper.cs, src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs, src/OpenClaw.Shared/SettingsData.cs)
• ranjeshj: The related merged zero-state chat PR refactored native chat/session-key behavior, which is adjacent context even though it does not cover this bootstrap prompt path. (role: adjacent chat/session contributor; confidence: medium; commits: 7747e6075052; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs, src/OpenClaw.Shared/OpenClawGatewayClient.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.

[github-actions]

🤖 This is an automated response from Repo Assist.

Good investigation in the issue report — the root cause is confirmed by source inspection.

Root Cause

OnboardingChatBootstrapper.ShouldBootstrap() and BootstrapAsync() gate on a single flag:

// Services/OnboardingChatBootstrapper.cs
public static bool ShouldBootstrap(SettingsManager settings)
    => !settings.HasInjectedFirstRunBootstrap;

HasInjectedFirstRunBootstrap defaults to false in SettingsData, so any user whose settings file pre-dates this field — or whose settings were regenerated — will retrigger the bootstrap prompt even with a fully configured gateway.

Suggested fix

Add a "user already has a configured gateway" guard. SetupExistingGatewayClassifier.HasAnyExistingGatewayConnection() already encapsulates this logic (checks both GatewayRegistry records and legacy operator device tokens):

public static bool ShouldBootstrap(
    SettingsManager settings,
    GatewayRegistry? registry = null,
    string? dataPath = null)
{
    if (settings.HasInjectedFirstRunBootstrap) return false;
    // Treat an already-configured workspace as not first-run.
    if (registry is not null && dataPath is not null
        && SetupExistingGatewayClassifier.HasAnyExistingGatewayConnection(registry, settings, dataPath))
    {
        // Mark to suppress future probes for this user.
        MarkBootstrapped(settings);
        return false;
    }
    return true;
}

This ensures existing/upgraded users are silently marked as bootstrapped on the first check, with no prompt sent. BootstrapAsync could receive the same guard.

A complementary improvement: call MarkBootstrapped(settings) at the end of a successful setup wizard completion (SetupWizardRunner / WizardPage) so the flag is set during initial setup, not only after the chat bootstrap run completes.

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

[github-actions]

🤖 This is an automated response from Repo Assist.

I've submitted a fix in PR #734: fix: guard bootstrap prompt against already-configured workspaces

Root cause confirmed: OnboardingChatBootstrapper.BootstrapAsync() only checked the HasInjectedFirstRunBootstrap flag, which could be false even when the workspace was already fully configured. The flag not being set can happen after a fresh app install over an existing workspace, a settings migration, or any reset.

Fix: Before sending the first-run prompt, the code now calls SetupExistingGatewayClassifier.HasAnyExistingGatewayConnection(). If an existing gateway configuration is found — via shared token, bootstrap token, or device token in the registry — the gate is silently consumed without sending the prompt. This prevents the bootstrap ritual from firing against an established workspace.

The change is backward-compatible: callers that don't pass a registry (or have an empty registry) get the existing first-run behavior unchanged.

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