Summary

What problem does this PR solve?

• Windows Startup-folder fallback installs currently launch the gateway through a visible cmd.exe hop.
• Even with start /min, Windows still flashes the terminal frame briefly at logon before minimizing it.
• This PR switches the Startup-folder fallback to a hidden .vbs launcher by default so the gateway starts without the visible console flash.

Why does this matter now?

• Fixes fix(windows): suppress startup-folder cmd window flash via wscript silent launcher #70788, where the per-user Startup fallback produced a distracting terminal flash on every Windows login.

What is the intended outcome?

• When Task Scheduler is unavailable and OpenClaw falls back to the Startup folder, the installed login item launches silently with no visible cmd.exe frame.

What is intentionally out of scope?

• No change to the main Task Scheduler install/update path.
• No change to the gateway command script itself (gateway.cmd).
• No change to runtime/service detection beyond continuing to recognize and clean up both .vbs and legacy .cmd Startup entries.

What does success look like?

• Startup fallback writes a hidden .vbs launcher by default.
• Existing stop/restart/uninstall flows still work with the new default and with legacy .cmd fallback entries.

What should reviewers focus on?

• resolveStartupEntryPath() now defaults the Startup-folder fallback to .vbs.
• activateScheduledTask() now always writes the hidden launcher for the Startup fallback path.
• The focused fallback tests still cover install, stop/restart, and legacy cleanup behavior.

Linked context

Which issue does this close?

Closes #70788

Which issues, PRs, or discussions are related?

Related #57682 for the same visible-console root cause on a different Windows launch path.

Was this requested by a maintainer or owner?

No maintainer request found; the issue is labeled clawsweeper:queueable-fix, clawsweeper:fix-shape-clear, and clawsweeper:source-repro.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Windows Startup-folder fallback no longer generates a visible cmd.exe launch hop by default.

• Real environment tested: local source checkout on macOS/Linux using the production Windows fallback installer path under mocked schtasks denial and Windows env in the daemon Vitest suites.

• Exact steps or command run after this patch:

  • node scripts/run-vitest.mjs src/daemon/schtasks.startup-fallback.test.ts src/daemon/schtasks.install.test.ts src/daemon/schtasks.test.ts src/daemon/schtasks.stop.test.ts

• Evidence after fix:

  Startup fallback install now writes the Startup entry as .vbs by default.
  The generated launcher contains:
  CreateObject("WScript.Shell").Run """<gateway.cmd>""", 0, False
  

• Observed result after fix: the fallback install tests now assert that the installed Startup entry is the hidden VBS launcher by default, while stop/restart/runtime tests continue to pass against the same fallback lifecycle.

• What was not tested: a live native Windows login session proving compositor-level no visible flash behavior. This environment does not provide an interactive Windows desktop.

• Proof limitations or environment constraints: the proof is limited to the production fallback-generation path and lifecycle tests, not a live Windows desktop login.

Tests and validation

Which commands did you run?

node scripts/run-vitest.mjs src/daemon/schtasks.startup-fallback.test.ts src/daemon/schtasks.install.test.ts src/daemon/schtasks.test.ts src/daemon/schtasks.stop.test.ts
git diff --check

What regression coverage was added or updated?

• Updated Startup fallback tests to assert the default installed login item is now .vbs.
• Existing lifecycle tests continue to cover fallback install, restart, stop, and uninstall/cleanup.

What failed before this fix, if known?

• The Startup-folder fallback used start "" /min cmd.exe /d /c ..., which still flashes a visible console frame before minimizing.

If no test was added, why not?

• Existing focused tests were updated for the new default behavior instead of adding a separate redundant case.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes.

Did config, environment, or migration behavior change? (Yes/No)

No.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

No.

What is the highest-risk area?

• Windows fallback lifecycle compatibility for installs that already have legacy .cmd Startup entries.

How is that risk mitigated?

• Uninstall and install-state checks already consider both .vbs and legacy .cmd paths, and the focused fallback lifecycle tests remain green after the default switch.

Current review state

What is the next action?

• ClawSweeper review and maintainer review.

What is still waiting on author, maintainer, CI, or external proof?

• CI and maintainer review.
• Live native Windows desktop proof is still unavailable in this environment.

Which bot or reviewer comments were addressed?

• No PR-thread comments yet; this is the initial implementation for fix(windows): suppress startup-folder cmd window flash via wscript silent launcher #70788.