Summary

On native Windows, running openclaw doctor from an elevated prompt updated a git/source checkout to the latest CLI/build, but did not migrate the managed gateway from the Startup-folder fallback to the proper OpenClaw Gateway Scheduled Task. It also left the already-running gateway process alive across the update, which caused stale dist chunk imports until a manual openclaw gateway restart was run.

This looks like an update/doctor repair gap for Windows fallback installs:

• the source/CLI updated to 2026.5.26
• no OpenClaw Gateway Scheduled Task exists after elevated doctor
• the Startup-folder fallback launcher remains installed
• %USERPROFILE%\.openclaw\gateway.cmd stayed stamped v2026.5.25
• the old live gateway process kept running after the update and hit missing generated-module errors from the new dist

Environment

• OS: native Windows 11
• OpenClaw checkout: git/source checkout
• CLI after doctor: OpenClaw 2026.5.26 (981ae13)
• Gateway port: 18789
• Doctor was run from an elevated prompt

What I expected

After an elevated doctor/update that refreshes a git/source checkout and reinstalls/repairs the gateway service, Windows should end in one of these safe states:

1. A real OpenClaw Gateway Scheduled Task is installed and points at the current launcher/build, or
2. doctor clearly reports why Scheduled Task install/repair was skipped/failed and that the install remains on Startup-folder fallback.

Also, if dist changes under a running gateway, doctor/update should replace or restart the live gateway process before status/RPC paths can hit stale generated chunk names.

What happened

Immediately after elevated doctor:

openclaw --version
# OpenClaw 2026.5.26 (981ae13)

git status --short --branch
# ## main...origin/main

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
# ERROR: The system cannot find the file specified.

openclaw gateway status --json still reported a fallback runtime, not a Scheduled Task runtime:

{
  "service": {
    "label": "Scheduled Task",
    "runtime": {
      "status": "running",
      "pid": 32136,
      "detail": "Startup-folder login item installed; listener detected on port 18789."
    }
  },
  "gateway": {
    "version": null
  },
  "rpc": {
    "ok": false,
    "error": "timeout"
  }
}

The Startup-folder fallback was still present:

Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" | Where-Object Name -like '*OpenClaw*'
# OpenClaw Gateway.cmd

The installed launcher script was stale after the update:

rem OpenClaw Gateway (v2026.5.25)
set "OPENCLAW_SERVICE_VERSION=2026.5.25"
"C:\Program Files\nodejs\node.exe" %USERPROFILE%\ai\openclaw\dist\index.js gateway --port 18789

The running process also predated the update/repair:

Get-CimInstance Win32_Process -Filter "ProcessId=32136" | Select-Object ProcessId,CreationDate,CommandLine
# ProcessId: 32136
# CreationDate: 2026-05-26 23:21:13
# CommandLine: node.exe ...\dist\index.js gateway --port 18789

Log evidence

After doctor updated files while the old gateway stayed alive, the gateway hit stale generated module imports:

request handler failed: Error: Cannot find module '<repo>\dist\task-registry.maintenance-Bv3uw6K9.js' imported from '<repo>\dist\status.summary-BI5NLNZF.js': code=ERR_MODULE_NOT_FOUND
Health check failed: GatewayTransportError: gateway timeout after 3000ms

Earlier in this same local investigation, the same class of stale chunk failure appeared for channel message delivery after update:

Cannot find module '<repo>\dist\action-runtime-BNc9tdF4.js' imported from '<repo>\dist\probe-CsYjHBUH.js'

Manual recovery

A manual restart fixed the live process skew:

openclaw gateway restart
openclaw gateway status --json

After that:

{
  "service": {
    "runtime": {
      "status": "running",
      "pid": 24500,
      "detail": "Startup-folder login item installed; listener detected on port 18789."
    }
  },
  "gateway": {
    "version": "2026.5.26"
  },
  "rpc": {
    "ok": true
  }
}

So manual restart repaired the stale module graph, but the install still remained on Startup-folder fallback and the fallback launcher was still stamped v2026.5.25.

Why this seems distinct from related Windows task issues

I found related fixed issues for Windows Scheduled Task no-op runs, stale/orphaned gateway processes, and automatic gateway startup, but those fixes mostly cover the Scheduled Task path or no-listener fallback behavior. This report is about an elevated doctor/update run failing to migrate/repair a fallback install into the Scheduled Task path and failing to replace the live gateway after dist changed.

Suggested fix direction

• During openclaw doctor / update repair on Windows, if running elevated and the install is on Startup-folder fallback, retry Scheduled Task installation or clearly report why migration was skipped.
• Refresh %USERPROFILE%\.openclaw\gateway.cmd and the Startup-folder launcher when the service version changes, even if remaining on fallback.
• Ensure update/doctor restarts or respawns the live gateway after changing dist, so stale generated chunk imports cannot survive across the update.
• Make gateway status clearer when the service label is Scheduled Task but runtime is actually Startup-folder fallback.

Impact

The machine appears updated, but the live gateway can remain on stale runtime state and become partially broken. The user sees a listener on 18789, but RPC/status can time out or fail with ERR_MODULE_NOT_FOUND until a manual restart is performed.