#Issue Report: Windows Path Warnings & Background Execution,

1 messages · Page 1 of 1 (latest)

wide lintel
#

Persistent "Skipping skill path" Warnings

Symptom: Every time I run an openclaw command or start the gateway, the terminal is flooded with:[skills] Skipping skill path that resolves outside its configured root.
Context: Most skills (e.g., claw-me-maybe) are still functional and marked as âś“ ready, but the log noise is extreme.
Environment: Windows 11. I suspect there's a discrepancy in how ~ or absolute paths are resolved against skills.roots on Windows. Is there a way to explicitly define the roots or suppress this check?

Background Execution on Windows

Need: Running OpenClaw in an active PowerShell window is inconvenient for daily use.
Goal: I'm looking for the best way to run the Gateway as a silent background service on Windows (similar to a Linux daemon). Ideally, it should:
Start automatically on boot.
Run without a visible console window.
Restart gracefully on failure.
Current Attempt: Using openclaw gateway start, but still looking for a more robust Windows-native service solution (e.g., PM2, NSSM, or Task Scheduler).

System Specs:
OS: Windows 11 (NT 10.0.26200)
Node.js: v24.14.0
OpenClaw: 2026.3.12

cloud brookBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

scarlet domeBOT
#

1) [skills] Skipping skill path that resolves outside its configured root

That message is coming from a deliberate safety guard: when OpenClaw scans a skill root (bundled, ~/.openclaw/skills, <workspace>/skills, or skills.load.extraDirs), it rejects any skill where the resolved real path of the folder or SKILL.md ends up outside that root (usually because of symlinks/junctions).

So it’s not a “~ expansion” check you can override with something like skills.roots (that key doesn’t exist). The configurable part is where we scan:

  • default locations +
  • skills.load.extraDirs (lowest precedence)

Docs:

How to fix (Windows-friendly approach):

  • If you have a “skills folder” full of symlinks/junctions to repos elsewhere, don’t point OpenClaw at the symlink container.
  • Instead, add the real target directories directly to skills.load.extraDirs, or copy the skill folders so they physically live under the scanned root.
#

To identify the exact offender, paste one warning line that includes the metadata fields (it logs source, rootDir, path, realPath). That immediately tells whether it’s coming from:

  • openclaw-extra (your skills.load.extraDirs)
  • openclaw-workspace (<workspace>/skills)
  • openclaw-managed (~/.openclaw/skills)
  • openclaw-bundled (would be interesting—might indicate a packaging/path oddity)

Suppressing the noise (if you just want your terminal back):
You can’t selectively disable only this guard, but you can lower console verbosity globally:

// ~/.openclaw/openclaw.json
{
  logging: {
    consoleLevel: "error" // hides warn spam (but also hides other warnings)
  }
}
#

Docs: https://docs.openclaw.ai/gateway/logging

2) Running the Gateway as a background service on Windows

On Windows, the “native” route is: install the Gateway service — OpenClaw uses Task Scheduler (schtasks) under the hood.

Use:

openclaw gateway install
openclaw gateway status --deep

Then manage it with:

# 
openclaw gateway start
openclaw gateway stop
openclaw gateway restart

CLI docs: https://docs.openclaw.ai/cli/gateway
(Also note openclaw daemon ... is the legacy alias.)

Two important caveats for your exact requirements:

  • The built-in scheduled task is currently ONLOGON (starts when you log in), not “pre-login at boot”.
  • “Restart on failure” is more limited with plain schtasks than with systemd/NSSM (you can add retry behavior in Task Scheduler UI, but it’s not as nice as a real service supervisor).

If you want true “boot + supervised + silent” on Windows: the docs recommendation is WSL2 + systemd (it’s the most reliable operationally), including the “start WSL at boot” chain:
https://docs.openclaw.ai/platforms/windows