Title

gateway status reports unknown / staleGatewayPids on localized Chinese Windows even when Scheduled Task Gateway is running

Summary

On a Chinese-localized Windows host, OpenClaw reports the managed Gateway runtime as unknown and marks the actual listener PID as staleGatewayPids, even though the Scheduled Task is installed and the Gateway is actively listening.

This appears to be caused by parsing localized schtasks /Query /V /FO LIST output using English field names.

Environment

• OS: Windows 11, Chinese locale
• OpenClaw: 2026.3.23-2
• Gateway install mode: Scheduled Task (\\OpenClaw Gateway)
• Listener: ws://127.0.0.1:18789

Observed behavior

• openclaw gateway status --json / openclaw status --deep reports the Gateway service runtime as unknown
• health includes staleGatewayPids
• but the Scheduled Task exists and the Gateway is actually alive / listening
• logs repeatedly show:
  • gateway already running under schtasks; waiting 5000ms before retrying startup
  • heartbeat / listener startup activity

What was confirmed locally

1. There was an old gateway.cmd drift issue first (old wrapper script version), but that was repaired.
2. After rebuilding the managed Gateway service with the current CLI, the Gateway process was still alive and listening correctly.
3. The remaining dirty status persisted even after the wrapper drift was fixed.
4. Dist code inspection suggests the Windows runtime parser expects English keys from schtasks, including:
   • status
   • last run time
   • last run result
5. On a Chinese-localized system, schtasks output is localized, so those fields do not parse correctly.
6. Because runtime status falls through to unknown, the health logic then treats the real listener PID as stale.

Likely cause

parseSchtasksQuery() appears to read schtasks /Query /TN <task> /V /FO LIST using English key names only.

On localized Windows hosts, that breaks runtime-state detection, which then cascades into a misleading health result (staleGatewayPids).

Expected behavior

• Localized Windows should still report the Scheduled Task runtime as running when the task is healthy.
• A healthy listener PID should not be marked stale solely because schtasks output was localized.

Relevant code paths observed locally

• dist/service-DdJ2Qk7P.js
  • parseSchtasksQuery()
  • readScheduledTaskRuntime()
• dist/status-B6f3xZ42.js
  • Windows fallback logic that can classify busy-port listeners as stale when runtime.status !== "running"

Suggested fix

One of these would likely solve it:

1. Stop relying only on localized schtasks /FO LIST text parsing.
2. Use a Windows-native structured source instead, e.g. PowerShell ScheduledTasks APIs:
   • Get-ScheduledTask
   • Get-ScheduledTaskInfo
3. Or add locale-aware field mapping / structured parsing.
4. Avoid the stale-PID fallback when the task is confirmed alive by an alternate Windows-native task API.

Extra note

A separate local noise source also existed: bad delivery-queue items targeting channel=feishu, to=heartbeat. Those were isolated locally, but they were not the root cause of the Scheduled Task runtime being reported as unknown.