Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On a Spanish-locale Windows host, openclaw node install --host 127.0.0.1 --port 18789 --display-name "Windows Node" --runtime node --force --json exits with Node install failed: Error: schtasks create failed: Error: Acceso denegado. instead of taking the existing Startup-folder fallback path.

Steps to reproduce

1. On a Windows host where schtasks /Create is denied for the current user and stderr is localized to Spanish, set a valid gateway token in OPENCLAW_GATEWAY_TOKEN.
2. Run openclaw node install --host 127.0.0.1 --port 18789 --display-name "Windows Node" --runtime node --force --json.
3. Observe the install exit non-zero with schtasks create failed: Error: Acceso denegado..
4. Observe %USERPROFILE%\.openclaw\node.cmd exists, but there is no OpenClaw Node Scheduled Task and no Startup-folder launcher at %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\OpenClaw Node.cmd.

Expected behavior

When Scheduled Task creation is denied, node install should take the existing per-user Startup-folder fallback path instead of failing the install. That fallback is already present for English ERROR: Access is denied. and for schtasks timeout/no-output cases.

Actual behavior

The install exits with:

{
  "action": "install",
  "ok": false,
  "error": "Node install failed: Error: schtasks create failed: Error: Acceso denegado."
}

After that failed install, node status --json showed a partial install with sourcePath at %USERPROFILE%\.openclaw\node.cmd, loaded: false, and runtime detail Error: El sistema no puede encontrar el archivo especificado..

Gateway-side nodes status --json showed the Windows node paired but disconnected with empty caps and commands.

OpenClaw version

2026.5.4

Operating system

Windows_NT 10.0.26200 (Spanish locale)

Install method

Reproduced with pnpm openclaw from a repo worktree. The same failure was also observed with a workspace-local npm-installed openclaw 2026.5.4 CLI package.

Model

Not applicable. No model request is involved in openclaw node install.

Provider / routing chain

Not applicable. No model/provider routing is involved in openclaw node install.

Additional provider/model setup details

Node install path only. The relevant runtime dependency is a reachable gateway plus a valid OPENCLAW_GATEWAY_TOKEN; no model/provider auth path was exercised.

Logs, screenshots, and evidence

openclaw node install --host 127.0.0.1 --port 18789 --display-name "Windows Node" --runtime node --force --json

{
  "action": "install",
  "ok": false,
  "error": "Node install failed: Error: schtasks create failed: Error: Acceso denegado."
}

openclaw node status --json

{
  "service": {
    "label": "Scheduled Task",
    "loaded": false,
    "loadedText": "registered",
    "notLoadedText": "missing",
    "command": {
      "sourcePath": "C:\\Users\\Agustin\\.openclaw\\node.cmd"
    },
    "runtime": {
      "status": "unknown",
      "detail": "Error: El sistema no puede encontrar el archivo especificado.",
      "missingUnit": false
    }
  }
}

schtasks /Query /TN "OpenClaw Node" /V /FO LIST

Error: El sistema no puede encontrar el archivo especificado.

nodes status --json

{
  "nodes": [
    {
      "displayName": "Windows Node",
      "platform": "win32",
      "paired": true,
      "connected": false,
      "caps": [],
      "commands": []
    }
  ]
}

Impact and severity

Affected: Windows node installs on this Spanish-locale Windows host when Scheduled Task creation is denied for the current user.
Severity: High. It blocks persistent node install and leaves the node offline.
Frequency: 2/2 observed install attempts before the matcher fix.
Consequence: Windows node capabilities such as browser.proxy, system.run, and system.which are unavailable until the operator either runs openclaw node run manually in the foreground or installs from an elevated shell.

Additional information

Code inspection showed the fallback matcher in src/daemon/schtasks.ts only recognized /access is denied/i, so Spanish Acceso denegado missed the fallback even though the Startup-folder path already exists.

On this host, the localized schtasks failure did not reliably come back with exit code 5; the observed failing case still emitted Error: Acceso denegado. while the install aborted.

A local patch that broadened the matcher to include Windows access-denied exit code 5, English access denied, and Spanish acceso denegado, plus a regression test in src/daemon/schtasks.startup-fallback.test.ts, allowed the same host to create the Startup-folder launcher successfully. After that, the new node connected with:

• caps: ["browser", "file", "system"]
• commands: ["browser.proxy", "system.run", "system.run.prepare", "system.which"]

Observed workaround before the patch: run openclaw node run --host 127.0.0.1 --port 18789 --display-name "Windows Node" in the foreground, or install from an elevated PowerShell session.