Summary

Add an optional Windows logon task that opens the Control UI after the managed gateway is reachable, without spawning a console window or starting another gateway process.

Problem to solve

On Windows, users who want the OpenClaw Control UI (OpenClaw Dashboard) available automatically after login currently have weak options.

Running openclaw dashboard --yes from startup can create or flash a PowerShell/cmd window. It can also race the managed gateway task during login. If the gateway is not ready yet, the dashboard command may enter a path that starts, installs, or otherwise manages the gateway, which mixes two separate responsibilities:

• gateway lifecycle management
• dashboard/UI opening

A manual browser bookmark avoids duplicate startup, but it does not solve automatic Control UI availability after reboot or login.

This is especially noticeable on operator workstations where OpenClaw is expected to come up quietly and predictably every day.

Proposed solution

Add a Windows-only optional “dashboard opener” as part of Windows onboarding or managed gateway setup.

Desired behavior:

• The existing managed gateway task remains the only task responsible for starting or supervising the gateway.
• A separate scheduled task, for example OpenClaw Dashboard, is created only when the user opts in.
• The dashboard opener runs at user logon with a short delay, for example 15 seconds.
• It waits for the configured local gateway URL to respond, for example http://127.0.0.1:<gateway.port>/.
• Once the gateway is reachable, it opens the Control UI using the Windows shell/default browser.
• If the gateway is not reachable within a timeout, it exits silently.
• It must not invoke any CLI path that can install, start, restart, or supervise the gateway.
• It should be idempotent: rerunning onboarding should update the opener task if needed, not create duplicates.
• Uninstall or daemon cleanup should remove the opener task if OpenClaw created it.

Suggested UX:

Open Control UI automatically after Windows login? [yes/no]

Suggested internal model:

gateway autostart = managed gateway task
dashboard autostart = opener-only task that waits for gateway health and opens URL

Acceptance criteria:

• Enabling the option creates or updates exactly one dashboard opener task.
• The opener does not call openclaw dashboard --yes, openclaw gateway, or any command that can start/install the gateway.
• The opener exits cleanly if the gateway does not become reachable within the configured timeout.
• Re-running onboarding does not create duplicate opener tasks.
• Removing the managed Windows setup removes the opener task created by OpenClaw.

Alternatives considered

Using powershell.exe -WindowStyle Hidden -Command "Start-Process ...":
This can still flash or leave a PowerShell process depending on the caller and host context. It also keeps the behavior tied to a shell command rather than a managed OpenClaw setup path.

Using a .vbs wrapper that runs openclaw dashboard --yes hidden:
This hides the window, but it still risks duplicate gateway startup because dashboard --yes can try to start or install the gateway if the managed gateway task has not finished booting.

Using a Startup folder shortcut:
This is less manageable, harder to make idempotent, and not integrated with OpenClaw’s install/uninstall lifecycle.

Using only a browser bookmark:
This avoids startup risk but does not solve automatic Control UI availability after reboot or login.

Impact

Affected users/systems/channels: Windows users running OpenClaw as a local workstation operator console, especially users who depend on the Control UI being available after reboot or login.

Severity: Medium. This does not usually break the gateway, but it creates visible startup noise and lifecycle ambiguity around whether the dashboard opener or the managed gateway task is responsible for gateway startup.

Frequency: Daily for users who reboot or log in frequently and expect OpenClaw to be ready without manual steps.

Consequence: Extra manual checks, delayed dashboard access, noisy startup behavior, and avoidable confusion about whether one or multiple gateway processes are running.

In shared operator workflows, this can become a recurring operational tax because users have to verify that the gateway is running, confirm the dashboard is reachable, and clean up any accidental duplicate startup paths.

Evidence/examples

##Local Windows validation:

OS: Windows <version>
OpenClaw version: <version>
Install method: <npm / PowerShell installer / other>
Gateway port: 18789
Existing gateway task: OpenClaw Gateway
Added opener task: OpenClaw Dashboard
Gateway listener: single process on 127.0.0.1:18789
Dashboard opener task result: LastTaskResult = 0

##Observed result:

• The dashboard opener completed successfully.
• No new openclaw dashboard --yes process was created.
• No second openclaw.mjs gateway run process was created.
• The existing managed gateway task remained the only gateway lifecycle owner.

##Reference implementation used locally:

Option Explicit

Dim shell
Dim url
Dim ready
Dim i

Set shell = CreateObject("WScript.Shell")
shell.CurrentDirectory = "C:\Users\<user>"

url = "http://127.0.0.1:18789/"
ready = False

For i = 1 To 60
  If IsGatewayReady(url) Then
    ready = True
    Exit For
  End If

  WScript.Sleep 1000
Next

If ready Then
  shell.Run "rundll32.exe url.dll,FileProtocolHandler " & url, 0, False
End If

Function IsGatewayReady(targetUrl)
  Dim http

  On Error Resume Next
  Set http = CreateObject("MSXML2.ServerXMLHTTP.6.0")
  http.SetTimeouts 1000, 1000, 1000, 1000
  http.Open "GET", targetUrl, False
  http.Send

  IsGatewayReady = (Err.Number = 0 And http.Status >= 200 And http.Status < 500)
  Err.Clear
  On Error GoTo 0
End Function

##Example scheduled task shape:

$action = New-ScheduledTaskAction `
  -Execute "$env:WINDIR\System32\wscript.exe" `
  -Argument '"%USERPROFILE%\.openclaw\dashboard-hidden.vbs"'

$trigger = New-ScheduledTaskTrigger -AtLogOn -User "$env:USERDOMAIN\$env:USERNAME"
$trigger.Delay = 'PT15S'

$settings = New-ScheduledTaskSettingsSet `
  -AllowStartIfOnBatteries `
  -DontStopIfGoingOnBatteries `
  -ExecutionTimeLimit (New-TimeSpan -Minutes 2) `
  -MultipleInstances IgnoreNew `
  -StartWhenAvailable

$settings.Hidden = $true

Additional information

The important design constraint is separation of responsibility:

• Gateway task: starts and supervises the gateway.
• Dashboard opener task: only waits for the gateway to become reachable and opens the Control UI.

The local script above is only a working reference implementation, not a requested implementation requirement. For maintainability, this should likely live inside OpenClaw’s Windows onboarding/managed gateway setup code - a native TypeScript renderer for the Windows task and helper script would be easier to test, update, and remove during uninstall.