PR #81267: fix(node): hide Windows node task launcher

• Repository: openclaw/openclaw
• Author: giodl73-repo
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/81267

Description (problem / solution / changelog)

Summary

• Problem: openclaw node install writes the Windows node login task as a direct node.cmd target, which can leave a persistent command window open after login.
• Why it matters: the node host is documented and expected to run in the background; a visible command window is noisy and makes the install feel broken.
• What changed: node service installs now opt into a hidden Windows launcher. The shared scheduled-task installer writes the normal .cmd script plus a sibling .vbs launcher, points the Windows task at the launcher, and uses the same hidden launcher for the Startup-folder fallback.
• What did not change: the gateway scheduled task continues to use the existing .cmd path unless it opts in, and node status/restart/script behavior still uses the generated node.cmd script.

Change Type

• Bug fix

Scope

• CLI / DX
• Gateway / orchestration

Linked Issue/PR

Closes #81254

Real Behavior Proof

Behavior or issue addressed: Windows node install now starts through a hidden launcher instead of leaving a persistent command window.

Real environment tested: Local Windows source checkout. Creating a real ONLOGON scheduled task is denied on this machine, so the proof exercised OpenClaw's real Windows install path through its Startup-folder fallback. The scheduled-task /TR node.vbs path is covered by the unit tests below.

Exact steps or command run after this patch:

1. Ran a Node script that imports installScheduledTask with a temp OPENCLAW_STATE_DIR, temp OPENCLAW_WINDOWS_TASK_NAME, OPENCLAW_TASK_SCRIPT_NAME=node.cmd, OPENCLAW_WINDOWS_TASK_HIDDEN_LAUNCHER=1, and a harmless cmd.exe /d /c exit 0 command.
2. Let the local schtasks /Create /SC ONLOGON attempt fail with access denied, triggering OpenClaw's existing Startup-folder fallback.
3. Read the generated launcher and cleaned up the temp install.

Evidence after fix:

Copied live output from the local OpenClaw install-path proof:

{
  "scriptName": "node.cmd",
  "launcherName": "node.vbs",
  "launcherUsesWscriptShell": true,
  "launcherRunsHidden": true,
  "installOutput": [
    "Installed Windows login item: C:\\Users\\giodl\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\OpenClawNodeProof40488.vbs",
    "Task script: C:\\Users\\giodl\\AppData\\Local\\Temp\\openclaw-node-task-proof-PLQg1Z\\node.cmd"
  ]
}

Observed result after fix: The fallback installed node.vbs, and the launcher uses WScript.Shell.Run(..., 0, False) so the command host is hidden. Before this change, #81254 shows openclaw node install creating node.cmd, Logon Mode: Interactive only, and a persistent visible openclaw-node command window at login.

What was not tested: A successful real ONLOGON scheduled-task creation and sign-in on this local machine, because schtasks /Create returned access denied. The scheduled-task path is covered by the tests, including the /TR ...node.vbs assertion.

Additional scheduled-task proof

Because local schtasks /Create /SC ONLOGON is denied in this shell, I registered the generated PR launcher with Windows Task Scheduler directly and verified it through schtasks /Query. This exercises a real Windows At logon task whose action is the generated hidden node.vbs launcher.

Generated launcher from the PR code:

' OpenClaw Node hidden launcher proof
CreateObject("WScript.Shell").Run """C:\Users\giodl\AppData\Local\Temp\openclaw-node-real-task-proof-73cUCv\.openclaw\node.cmd""", 0, False

Task query before run:

TaskName:                             \OpenClawNodeProof28336
Status:                               Ready
Logon Mode:                           Interactive only
Last Run Time:                        11/30/1999 12:00:00 AM
Last Result:                          267011
Task To Run:                          C:\Users\giodl\AppData\Local\Temp\openclaw-node-real-task-proof-73cUCv\.openclaw\node.vbs
Schedule Type:                        At logon time
Run As User:                          giodl

After Start-ScheduledTask -TaskName OpenClawNodeProof28336:

TaskName:                             \OpenClawNodeProof28336
Status:                               Ready
Last Run Time:                        5/12/2026 11:53:05 PM
Last Result:                          0
Task To Run:                          C:\Users\giodl\AppData\Local\Temp\openclaw-node-real-task-proof-73cUCv\.openclaw\node.vbs
Schedule Type:                        At logon time

Marker written by the generated node.cmd through the hidden launcher:

proof-28336

Observed process check after completion:

{
  "MatchingProcesses": null
}

This proves the generated hidden launcher is a real Windows scheduled-task action and the task completes through node.vbs without leaving a matching cmd, conhost, wscript, or cscript process behind. I still could not capture an actual sign-out/sign-in artifact from this shell; this is the closest local proof without creating an interactive login cycle.## Root Cause

The shared Windows scheduled-task installer wrote direct .cmd task targets, and the node service reused that default even though node is expected to behave like a background service. There was no node-specific test requiring a hidden Windows launcher.

Regression Test Plan

Ran:

.\node_modules\.bin\oxfmt.CMD --check --threads=1 CHANGELOG.md src/daemon/schtasks.ts src/daemon/schtasks.install.test.ts src/daemon/schtasks.startup-fallback.test.ts src/daemon/node-service.ts src/daemon/service-env.ts src/daemon/service-env.test.ts
node scripts/test-projects.mjs src/daemon/schtasks.install.test.ts src/daemon/schtasks.startup-fallback.test.ts src/commands/node-daemon-install-helpers.test.ts src/cli/node-cli/register.test.ts src/daemon/service-env.test.ts --reporter=verbose
node scripts/check-changed.mjs
node scripts/run-tsgo.mjs -p test/tsconfig/tsconfig.core.test.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core-test.tsbuildinfo
git diff --check

Coverage added:

• Scheduled-task install writes node.vbs and points /TR at the hidden launcher when node opts in.
• Existing scheduled tasks are updated to use the hidden launcher.
• Startup-folder fallback writes a hidden .vbs launcher when node opts in.
• Node service env marks Windows node installs for hidden launcher startup.

User-visible / Behavior Changes

On Windows, openclaw node install launches the node host through a hidden launcher. Users should no longer see a persistent command window from the node login task.

Security Impact

No new permissions, network access, secret handling, or data access. The generated launcher only invokes the existing generated task script in hidden mode.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/daemon/node-service.ts (modified, +2/-0)
• src/daemon/schtasks.install.test.ts (modified, +62/-0)
• src/daemon/schtasks.startup-fallback.test.ts (modified, +58/-2)
• src/daemon/schtasks.ts (modified, +93/-23)
• src/daemon/service-env.test.ts (modified, +11/-0)
• src/daemon/service-env.ts (modified, +1/-0)

PR #81330: fix(windows): suppress persistent cmd window from scheduled-task node launch

• Repository: openclaw/openclaw
• Author: only1OvO
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/81330

Description (problem / solution / changelog)

Problem

On Windows, openclaw node install creates a Scheduled Task that runs the ode.cmd script at login. Because uildTaskScript() runs the node process directly, cmd.exe blocks until the node process exits - leaving a persistent visible cmd window in the taskbar.

Fixes #81254

Root cause

uildTaskScript() pushes the raw ode.exe args... line as the final command in the generated .cmd script. When this script runs via Windows Scheduled Task with /IT (interactive), cmd.exe blocks on the long-running node process, keeping the console window open and visible.

Fix

Wrap the final command with start "" /b so the launched process runs in the same console's background. cmd.exe completes the batch file and exits immediately. The window closes after a brief appearance instead of persisting.

This mirrors the same approach used in launchFallbackTaskScript() which already uses windowsHide: true via Node.js spawn, and is consistent with the startup folder fallback's start "" /min pattern.

Testing

• On Windows 11: openclaw node install, sign out/in, verify no persistent visible cmd window in taskbar
• openclaw node status still shows running
• openclaw node stop / openclaw node start still work

Changed files

• src/daemon/schtasks.ts (modified, +6/-1)

PR #74163: WORKING: All Microsoft Issues and PRs (refresh)

• Repository: openclaw/openclaw
• Author: BradGroux
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/74163

Description (problem / solution / changelog)

Microsoft Ecosystem Issues & PRs Tracker

Purpose: Living checklist for maintainers to track all open Microsoft-related issues and PRs (Teams, Windows, WSL, Azure, M365/SharePoint).

How to use:

• Mark items resolved by editing this PR body and changing [ ] to [x]
• Claim items by adding your GitHub handle to the Assignee column
• Priority guide: P0 = crash/blocker/security, P1 = significant bug/regression, P2 = minor bug/enhancement, P3 = nice-to-have/stale
• Items marked (stale) have been flagged by the stale bot due to inactivity

Last updated: 2026-05-13 (closed #81106 and #38846; merged #74383 and verified #74350 closure; Microsoft-scope scrub retained)

Summary

1. MS Teams Channel Plugin — Issues

Bugs / Crashes

Feature Requests

2. MS Teams Channel Plugin — PRs

3. Windows Platform — Issues

Bugs / Crashes

Feature Requests

4. Windows Platform — PRs

5. WSL (Windows Subsystem for Linux) — Issues

Bugs / Crashes

Feature Requests

No currently open items found.

6. WSL (Windows Subsystem for Linux) — PRs

7. Azure (Provider / Infrastructure) — Issues

Bugs / Crashes

Feature Requests

8. Azure (Provider / Infrastructure) — PRs

9. Microsoft 365 / SharePoint — Issues

Bugs / Crashes

No currently open items found.

Feature Requests

No currently open items found.

10. Microsoft 365 / SharePoint — PRs

No currently open items found.

Appendix: P0 Blockers (Start Here)

Appendix: High-Priority Bugs / Regressions

Appendix: Stale Items (Consider Closing)

No matching items found.

Audit Notes

• Rebuilt from the format of PR #49126 after the issue/PR purge.
• Reapplied Microsoft-scope filtering on 2026-05-13 after the rebuild reintroduced generic false positives; SQLite/session runtime, generic plugin/runtime, non-Microsoft "window" noun matches, and generic Azure-section rows were removed.
• Removed merged PR #63074 from the current-open tracker on 2026-05-13 after maintainer review and squash merge.
• Removed closed PR #81106 from the current-open tracker on 2026-05-13 after maintainer review.
• Removed merged PR #74383 and closed issue #74350 from the current-open tracker on 2026-05-13 after maintainer review, squash merge, and automatic issue closure.
• Removed closed PR #38846 from the current-open tracker on 2026-05-13 after maintainer review found unresolved Windows command-execution correctness and secret-disclosure blockers.
• Source set is currently open GitHub issues and PRs from openclaw/openclaw; closed counts are intentionally reset to 0 for this refreshed tracker.
• Included title/label matches for msteams, Microsoft Teams, Windows, WSL, Azure, Entra/AAD, MSAL, managed identity, DefaultAzureCredential, Microsoft Graph, SharePoint, OneDrive, and Microsoft 365.
• Kept broad multi-channel PRs when they carry channel: msteams, because those can still affect the Microsoft surface area.
• Generated with node scripts/generate-microsoft-tracker.mjs so the tracker and PR body can be refreshed after future triage passes.

Changed files

• CHANGELOG.md (modified, +1/-0)
• MICROSOFT_TRACKER.md (added, +365/-0)
• scripts/generate-microsoft-tracker.mjs (added, +428/-0)