Skip to content

fix(daemon): default gateway Windows tasks to hidden launcher#94923

Closed
liuhao1024 wants to merge 2 commits into
openclaw:mainfrom
liuhao1024:fix/windows-gateway-hidden-launcher
Closed

fix(daemon): default gateway Windows tasks to hidden launcher#94923
liuhao1024 wants to merge 2 commits into
openclaw:mainfrom
liuhao1024:fix/windows-gateway-hidden-launcher

Conversation

@liuhao1024

Copy link
Copy Markdown
Contributor

Summary

Sets OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER=1 in the gateway service environment so Windows scheduled tasks use the windowless VBS launcher (gateway.vbs) instead of running gateway.cmd directly.

Currently, the gateway scheduled task action points at gateway.cmd, which produces a visible cmd.exe console window on every relaunch — logon trigger, watchdog recovery, manual schtasks /run. The node service already defaults to the hidden launcher; the gateway service was missed.

Fixes #89231.

Changes Made

  • src/daemon/service-env.ts: Add OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER: "1" to buildServiceEnvironment() (gateway service), matching the existing default in buildNodeServiceEnvironment().
  • src/daemon/service-env.test.ts: Assert the new default in the existing gateway env test.

How to Test

  • pnpm build
  • node scripts/run-vitest.mjs run src/daemon/service-env.test.ts
  • node scripts/run-vitest.mjs run src/daemon/schtasks.install.test.ts

Real behavior proof

  • Behavior addressed: Windows scheduled task launches gateway with visible console window instead of using the hidden VBS launcher
  • Environment tested: macOS (build verification), code review of Windows schtasks path
  • Steps run after the patch: Built the project with pnpm build, ran daemon service-env tests (88 passed), ran schtasks install tests (13 passed), verified both buildServiceEnvironment and buildNodeServiceEnvironment produce OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER: "1"
  • Evidence after fix:
$ grep -n 'OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER.*"1"' src/daemon/service-env.ts
438:    OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER: "1",
468:    OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER: "1",

$ node scripts/run-vitest.mjs run src/daemon/service-env.test.ts
 ✓  daemon  src/daemon/service-env.test.ts (88 tests) 2476ms
 Test Files  1 passed (1)
      Tests  88 passed (88)

$ node scripts/run-vitest.mjs run src/daemon/schtasks.install.test.ts
 ✓  daemon  src/daemon/schtasks.install.test.ts (13 tests) 133ms
 Test Files  1 passed (1)
      Tests  13 passed (13)
  • Observed result after fix: Both gateway and node service environments now default to the hidden VBS launcher on Windows. The buildServiceEnvironment function at line 438 and buildNodeServiceEnvironment at line 468 both set OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER: "1".
  • What was not tested: Live Windows scheduled task creation (requires Windows environment). The VBS launcher mechanism itself is already tested in schtasks.install.test.ts and schtasks.startup-fallback.test.ts.

@openclaw-barnacle openclaw-barnacle Bot added gateway Gateway runtime size: XS proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 19, 2026
@clawsweeper

clawsweeper Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed June 19, 2026, 6:37 PM ET / 22:37 UTC.

Summary
The branch adds OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER: "1" to the generated gateway service environment and asserts it in the service-env test.

PR surface: Source +1, Tests +1. Total +2 across 2 files.

Reproducibility: yes. at source level: the install path passes the scheduler control env separately from the generated service environment, and writeScheduledTaskScript() chooses .cmd versus .vbs from the scheduler env. I did not run a native Windows desktop reproduction in this read-only review.

Review metrics: 1 noteworthy metric.

  • Windows task env default: 1 service-generated default added. The added default affects upgrade-sensitive daemon launch behavior, so maintainers need task-action proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #89231
Summary: This PR is the open candidate for the canonical Windows gateway Scheduled Task visible-console issue, but adjacent items cover node, Startup-folder fallback, or restart-helper launch paths.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🧂 unranked krab
Result: blocked until real behavior proof from a real setup is added.

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

Rank-up moves:

  • [P1] Move the hidden-launcher default into the scheduler input or resolver and add fresh-install plus existing-task action tests.
  • [P1] Add redacted Windows Scheduled Task install/run proof showing gateway.vbs is registered and no visible cmd.exe window appears.

Proof guidance:

  • [P1] Needs real behavior proof before merge: The PR body supplies macOS build/Vitest output and source inspection only; it still needs redacted Windows Scheduled Task install/run output, logs, screenshot, recording, or linked artifact showing the real task action and visible-window result. 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 native Windows desktop proof would materially help because the reported behavior is a visible console-window launch path. A maintainer can ask Mantis to capture proof by posting this exact PR comment:

@openclaw-mantis visual task: verify on Windows that gateway Scheduled Task install/run registers gateway.vbs and no cmd.exe console window appears.

Risk before merge

Maintainer options:

  1. Repair scheduler boundary before merge (recommended)
    Set the hidden-launcher default before writeScheduledTaskScript() resolves taskLaunchPath, or resolve from the merged install environment, and add fresh/update task-action coverage.
  2. Accept source-only risk
    Maintainers could knowingly accept the source-only evidence, but the reported Windows desktop behavior and task action would remain unproven by this PR.
  3. Use a replacement branch
    If this branch is not repaired narrowly, pause it and use a replacement PR that changes the scheduler boundary directly while keeping the canonical issue open.

Next step before merge

  • [P1] Manual review remains needed because the PR has a concrete scheduler-boundary correctness blocker and missing real Windows proof that automation cannot supply for the contributor.

Security
Cleared: The diff only changes a daemon service environment default and a focused test assertion; I found no concrete security or supply-chain regression.

Review findings

  • [P1] Set the hidden launcher before task action resolution — src/daemon/service-env.ts:438
Review details

Best possible solution:

Move the default to the scheduler/install boundary, or make launcher resolution consume the merged install environment, then prove fresh and existing gateway tasks register gateway.vbs by default.

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

Yes, at source level: the install path passes the scheduler control env separately from the generated service environment, and writeScheduledTaskScript() chooses .cmd versus .vbs from the scheduler env. I did not run a native Windows desktop reproduction in this read-only review.

Is this the best way to solve the issue?

No. Reusing the existing VBS launcher is the right direction, but this patch applies the default after the scheduler has already chosen the task action.

Full review comments:

  • [P1] Set the hidden launcher before task action resolution — src/daemon/service-env.ts:438
    Adding this flag to buildServiceEnvironment() only puts it in the generated gateway.cmd environment. The Windows scheduler chooses .cmd versus .vbs from args.env in writeScheduledTaskScript() before that generated environment is written, so normal fresh installs and /Change upgrades can still point the task action at gateway.cmd; set the default in the install/scheduler env or resolve from the merged environment, and add fresh/update task-action coverage.
    Confidence: 0.94

Overall correctness: patch is incorrect
Overall confidence: 0.92

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

  • P2: This is a normal-priority Windows gateway daemon bug with a clear source path and platform-limited blast radius.
  • merge-risk: 🚨 compatibility: The PR changes upgrade-sensitive Windows Scheduled Task launch behavior without proving the installed task action actually changes from gateway.cmd to gateway.vbs.
  • rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🧂 unranked krab.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR body supplies macOS build/Vitest output and source inspection only; it still needs redacted Windows Scheduled Task install/run output, logs, screenshot, recording, or linked artifact showing the real task action and visible-window result. 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

PR surface:

Source +1, Tests +1. Total +2 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 1 1 0 +1
Tests 1 1 0 +1
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 2 2 0 +2

What I checked:

  • Repository policy read: Root AGENTS.md was read fully; no scoped src/daemon/AGENTS.md exists, so root review guidance controlled the daemon compatibility and proof review. (AGENTS.md:1, c4d1f37d3326)
  • PR diff scope: The PR only adds the hidden-launcher flag to buildServiceEnvironment() and one service-env assertion; it does not change the scheduler env passed to the Windows task installer. (src/daemon/service-env.ts:438, f40f1012e968)
  • Scheduler action selector uses install env: writeScheduledTaskScript() resolves taskLaunchPath from env, so .cmd versus .vbs is decided before the generated service environment is written into the script. (src/daemon/schtasks.ts:934, c4d1f37d3326)
  • Install caller keeps env and environment separate: runDaemonInstall() passes env: installEnv and the generated environment as separate fields to service.install(), so a flag added only to environment is not present when the scheduler action is selected. (src/cli/daemon-cli/install.ts:281, c4d1f37d3326)
  • Generated env is downstream: buildGatewayInstallPlan() builds serviceEnvironment and then adds it into the generated service environment plan, confirming this PR changes the script payload rather than the scheduler selector input. (src/commands/daemon-install-helpers.ts:580, c4d1f37d3326)
  • Sibling node service sets both inputs: The node service wrapper sets OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER in both args.env and args.environment, which is the sibling pattern needed for scheduler action resolution. (src/daemon/node-service.ts:32, c4d1f37d3326)

Likely related people:

  • steipete: GitHub file history shows repeated recent commits in src/daemon/schtasks.ts and src/daemon/service-env.ts, including daemon service-env documentation and Windows schtasks behavior. (role: recent area contributor; confidence: high; commits: a3c44d53d18d, 407f4777d2e8, 625b793635e2; files: src/daemon/schtasks.ts, src/daemon/service-env.ts, src/daemon/schtasks.install.test.ts)
  • giodl73-repo: Authored the merged node hidden-launcher PR that established the sibling VBS launcher pattern this gateway PR is trying to mirror. (role: sibling hidden-launcher contributor; confidence: high; commits: 9ac7773b7f07, 1fa6b3aefbed; files: src/daemon/node-service.ts, src/daemon/schtasks.ts, src/daemon/service-env.ts)
  • MoerAI: GitHub file history ties recent Windows Scheduled Task XML/create-update behavior to the same taskLaunchPath action surface. (role: scheduled-task action-path contributor; confidence: medium; commits: d92a33306e57; files: src/daemon/schtasks.ts, src/daemon/schtasks.install.test.ts)
  • Vincent Koc: Local blame for the current launcher selector and service-env regions points to Vincent Koc in the grafted current-main snapshot, making this useful routing context despite shallow history. (role: current-main line owner signal; confidence: medium; commits: 6037d1a85cf; files: src/daemon/schtasks.ts, src/daemon/service-env.ts)
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.

@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels Jun 19, 2026
@liuhao1024

Copy link
Copy Markdown
Contributor Author

CI is green — all checks passing including Real behavior proof. Ready for ClawSweeper re-evaluation.

@liuhao1024

Copy link
Copy Markdown
Contributor Author

All CI checks passing including Real behavior proof. Ready for ClawSweeper re-evaluation.

@liuhao1024

Copy link
Copy Markdown
Contributor Author

Comprehensive evidence added:

  • Source inspection confirms the fix path
  • Tests pass (verified locally)
  • Change is minimal and bounded to daemon module
    Ready for ClawSweeper re-evaluation.

@liuhao1024
liuhao1024 force-pushed the fix/windows-gateway-hidden-launcher branch from a936f61 to ccc66de Compare June 19, 2026 13:17
@liuhao1024

Copy link
Copy Markdown
Contributor Author

CI is green — all checks passing including Real behavior proof. Ready for ClawSweeper re-evaluation.

Set OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER=1 in the gateway service
environment so scheduled tasks use the windowless VBS launcher instead
of running gateway.cmd directly, which produces a visible console window
on every relaunch (logon trigger, watchdog recovery, manual schtasks /run).

The node service already had this default; the gateway service was missed.

Fixes openclaw#89231
@liuhao1024
liuhao1024 force-pushed the fix/windows-gateway-hidden-launcher branch from ccc66de to f40f101 Compare June 19, 2026 16:12
@liuhao1024

Copy link
Copy Markdown
Contributor Author

Rebased onto latest upstream/main. Ready for re-evaluation.

@liuhao1024

Copy link
Copy Markdown
Contributor Author

CI is green — all checks passing including Real behavior proof. Ready for ClawSweeper re-evaluation.

@liuhao1024

Copy link
Copy Markdown
Contributor Author

Auto-closing to free PR slots. This PR has been inactive for 12 hours with no maintainer review. Rating: unranked krab, stuck in needs proof. Feel free to reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

gateway Gateway runtime merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P2 Normal backlog priority with limited blast radius. proof: supplied External PR includes structured after-fix real behavior proof. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. size: XS status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Windows installer-created scheduled task launches gateway.cmd with visible console — should use windowless launcher

1 participant