solution gateway high windows

Windows: Gateway service fails to start when the user profile path is non-ASCII

Fix cases where `openclaw gateway start` works in the foreground but exits immediately when launched via Scheduled Task because the command path includes non-ASCII characters.

By CoClaw Team •

Symptoms

  • openclaw gateway start (background/service mode) exits immediately on Windows.
  • The same machine can run the Gateway in the foreground:
    • openclaw gateway run works, or
    • running the Node entrypoint manually works.
  • The install path for OpenClaw (or Node) includes a Windows user directory with non-ASCII characters (for example CJK characters), or other locale-sensitive path edge cases.

Cause

On native Windows, the Gateway “service” is typically implemented as a Scheduled Task.

If the Scheduled Task’s command line (or working directory / quoting) is constructed or persisted in a way that does not round-trip non-ASCII paths correctly, the background launcher can fail even though the underlying Node program can run fine.

This is why foreground runs can work while gateway start fails.

Fix

The most reliable operator workaround is to keep the global OpenClaw install path out of C:\Users\<non-ascii>\....

In PowerShell:

npm config set prefix C:\\openclaw-npm
npm install -g openclaw@latest

openclaw gateway uninstall
openclaw gateway install
openclaw gateway start

If you use pnpm for global installs, set its global dir to an ASCII-only location and reinstall similarly.

2) Confirm what the Scheduled Task is actually running

Before guessing, capture the exact command line:

openclaw gateway status --deep

If status --deep shows a command path under a non-ASCII user profile directory, apply Fix (1) and reinstall the task.

Verify

  • openclaw gateway status --deep shows the Gateway as running.
  • Opening the Control UI works (default: http://127.0.0.1:18789/ on the Gateway host).
  • Restart survives a stop/start cycle:
openclaw gateway stop
openclaw gateway start
  • OpenClaw CLI: Gateway
  • GitHub: #43943

Verification & references

  • Reviewed by:CoClaw Editorial Team
  • Last reviewed:March 14, 2026
  • Verified on: Windows

References

Official docs

  1. OpenClaw docs: /cli/gateway

Issue threads

  1. OpenClaw GitHub issue #43943
Want to explore more? Browse all solutions or ask in the Community Forum .
Report a problem

Related Resources

Windows native: node run hangs after printing PATH, or the runtime stays unstable
Fix
Stabilize native Windows setups where `openclaw node run` hangs after PATH output, the runtime behaves differently from your shell, or your real requirement is better served by WSL2.
Windows: tools.exec cannot find docker, rg, or gh even though they work in PowerShell
Fix
Fix native Windows cases where the Scheduled Task gateway uses a different PATH than your interactive shell, so tools.exec cannot resolve installed CLI tools.
Windows: 'openclaw' is not recognized after install
Fix
Fix Windows PATH issues after installing OpenClaw globally (npm prefix not on PATH, terminal not restarted, or multiple Node installs).
Gateway fails to start: EADDRINUSE / another gateway instance is already listening
Fix
Fix OpenClaw gateway port conflicts (EADDRINUSE) by stopping the other process or choosing a new gateway port/profile.
OpenClaw on Native Windows: PATH, Scheduled Tasks, Node Host, and the Real Failure Modes
Guide
A field guide to running OpenClaw on native Windows without guesswork. Learn why shell PATH and Scheduled Task PATH diverge, when `tools.exec.pathPrepend` helps or hurts, why `openclaw node run` can stall after printing PATH, and when WSL2 is the lower-risk choice.
OpenClaw on Windows: Native vs WSL2, Install Paths, and When to Switch
Guide
A practical decision guide for Windows users: when native Windows is good enough, when WSL2 is the safer default, which install path to choose, and how to migrate without turning your setup into a mystery.