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

1) Move the install prefix in use to an ASCII-only path

For affected native Windows installs, keep the OpenClaw install path used by the Scheduled Task 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 or another install method, move that install method’s global directory to an ASCII-only location and reinstall similarly. Do not switch package managers only for this workaround unless that is already part of your recovery plan.

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 Code 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: separate shell, Scheduled Task, and node-host environments; fix PATH-driven failures cleanly; and know when WSL2 is the faster exit.
OpenClaw on Native Windows: A Gateway Stability Playbook for SecretRefs, RPC Timeouts, and Cron Drift
Guide
A practical Windows operator guide for keeping OpenClaw stable when CLI SecretRef warnings disagree with gateway health, RPC probes time out under load, and cron jobs need a safer baseline.