[Bug] Native Gateway setup stops a progressing launch after 180s; same installation needs 210s to become ready

Open
  • Is something wrong?
#1,969 1 comment 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp
Domain
desktop

Research direction

Start in the setup flow at StepVerify, where NativeGatewaySetupSession.AuthorizeCoreAsync calls IsolatedGatewayRuntime.StartAndWaitAsync and EnsureRunningCoreAsync, and find where the 180-second budget and rollback are applied. Check how OPENCLAW_NATIVE_GATEWAY_START_TIMEOUT is read. Done means a launch that is still progressing is not rolled back at the default window, or the timeout behaviour and its GUI recovery path are clearly defined and tested.

Written by the indexing model from the issue text.

Description

clawsweeper:needs-maintainer-review clawsweeper:needs-product-decision clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:ux-release-blocker issue-rating: 🦞 diamond lobster P0

Summary

Native Windows Gateway setup fails at StepVerify because Companion's 180-second readiness budget expires while the package-managed Gateway is still making startup progress. Companion then rolls back the launch by stopping the Gateway.

On the same installation, a previous manual launch reached gateway ready after 210.474 seconds and the browser Control UI subsequently connected successfully after entering the existing Gateway token.

This report distinguishes the observed timeout/rollback behavior from the underlying startup slowness, whose cause has not been established.

Environment

  • Windows build: 10.0.28120.3393, x64
  • Store-signed Gateway MSIX: OpenClawFoundation.OpenClawGateway_2026.10.900.0_x64__rfcbke2p71se2
  • Packaging commit: 62c79e281fe997c4452d7494b660f0ac3bde51a4
  • Bundled OpenClaw: 2026.10.9, commit 8b18b5578f66eab1501cba4cef2310d88bfb9a41
  • Node.js: 24.22.1
  • MXC SDK: 1.0.1; isolated-session integration v1
  • Companion version was reported as 2026.9.8-1 in an earlier diagnostics export; the exact Companion build generating this latest setup log has not been independently verified.
  • Gateway endpoint: loopback, configured port 58415

Steps observed

  1. Run native Gateway setup through Windows Companion with the Store Gateway already installed.
  2. Package acquisition reports that the package is already installed and no upgrade is available.
  3. Configuration validation succeeds.
  4. Companion starts the package-managed Gateway and polls for a verified listener.
  5. The launch is acknowledged after about 91 seconds, but the listener is not ready within 180 seconds.
  6. Companion fails StepVerify and rolls back the Gateway start.

Actual behavior and attached log excerpts

These are selected excerpts from the local diagnostic exports; credentials, user/profile paths and session identifiers are omitted. Times below are local UTC+02:00 unless explicitly marked UTC.

Successful manual startup earlier on the same installation

From openclaw-diagnostics-20261101-105442:

12:48:44 Starting the gateway in the isolated session on its configured port.
12:50:16 Gateway start finished: Starting. The supervised gateway launch was accepted, but the gateway is not listening yet.
12:52:04 http server listening
12:52:15 gateway ready
12:52:15 startup phase: ready 1.2ms total=210474.1ms

The Control UI later opened directly in the browser and connected using the existing Gateway token. This confirms a successful Gateway/UI connection, not successful model inference.

Latest failed Companion setup

From native-setup-20261101-110745.jsonl (timestamps in UTC):

11:09:19 config validate --json exited 0:
{"valid":true,"warnings":[]}
stderr: CLI cleanup timed out: shared-state after 5000ms

11:09:23 Native setup step: StepVerify.
11:09:27 [WS] Native Gateway start requested on port 58415 (budget 180s).
11:10:58 [WS] Native Gateway start acknowledged after 91,4s.
11:11:01 [WS] Native Gateway startup status: gateway unhealthy, session running, readiness startup-eligible (gateway-mode-local).
11:12:27 [WS] The package-managed Gateway did not report a verified listener within 180 seconds of starting.
11:12:27 [WS] Rolling back the Gateway start requested by this attempt.
11:12:29 Native Gateway setup failed during StepVerify: NativeGatewayStartupTimeoutException

The exception identifies IsolatedGatewayRuntime.StartAndWaitAsync, then EnsureRunningCoreAsync, and NativeGatewaySetupSession.AuthorizeCoreAsync.

Gateway was still progressing immediately before rollback

From the newest launch log in openclaw-diagnostics-20261101-111309:

startup phase: cli.main.gateway-run-bootstrap 101604.0ms total=162436.5ms
13:12:11 loading configuration…
13:12:14 resolving authentication…
13:12:14 starting...
startup phase: cli.bootstrap.gateway-lock 11075.9ms total=177750.3ms
13:12:26 shutdown budget at startup: drain=315000ms shutdown=325000ms reserve=10000ms exitMargin=5000ms; source=Gateway stop policy=330000ms
startup phase: gateway.server-start-import starting total=177918.8ms

There is no gateway ready entry for this latest attempt before rollback. Logs also show long agent database activation/preparation and other bootstrap phases; they do not establish database corruption or a specific root cause for the slowness.

Expected behavior / request

Please review recovery behavior when a verified supervised launch remains alive and progresses beyond the default readiness window. Possible approaches include a longer documented budget or a resumable pending-start state, while preserving ownership checks and avoiding concurrent launches.

The current source exposes OPENCLAW_NATIVE_GATEWAY_START_TIMEOUT, but the normal GUI failure does not explain how a user should apply it and restart Companion safely. Clear GUI recovery guidance would help.

Related: #1903 concerns an already-starting native Gateway being rejected during automatic connection. This report concerns setup's explicit 180-second timeout followed by rollback.

Diagnostic handling

The complete local exports include configuration and backup files and are not uploaded publicly. The relevant error excerpts are included above. No tokens, credentials or personal paths are included in this report.

Dominant language
C#
Stars
2.2k
Forks
336
Avg merge
3d 18h
Merged PRs (30d)
177

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openclaw/openclaw-windows-node

All issues in openclaw/openclaw-windows-node

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.