Windows browser.proxy blocked: local listener owner could not be verified after clean WSL reinstall

[mietwagen26]

Environment

• Windows Companion: 2026.7.1-3
• Gateway: 2026.6.34
• WSL: OpenClawGateway, WSL 2
• Gateway: ws://127.0.0.1:18789
• Windows Node: online and paired
• Enabled capability: Browser only

Problem

Browser control fails with:

Browser control authentication was blocked because the local listener owner could not be verified.

Clean reinstall performed

1. Exported and verified the old WSL backup.
2. Unregistered the OpenClawGateway WSL distribution.
3. Uninstalled Windows Companion.
4. Removed %APPDATA%\OpenClawTray, including old gateway records and device identities.
5. Restarted Windows.
6. Confirmed zero WSL distributions, zero OpenClaw processes, and port 18789 unused.
7. Installed the signed x64 Companion 2026.7.1-3 installer.
8. Selected “Install a local gateway (WSL).”
9. Enabled Browser only. System, Canvas, Screen capture, Camera, Location, TTS, and STT were disabled.
10. Allowed Companion to create a new Ubuntu 24.04 OpenClawGateway.
11. Did not restore the old backup.

Verified working

• Gateway service is running.
• Port 18789 is listening.
• Gateway RPC is OK.
• Windows Node is online and paired.
• browser.proxy is approved and effective.
• No browser proxy allowlist entry is missing.

Actual result

{
  "ok": false,
  "checks": [
    {
      "name": "gateway",
      "ok": false,
      "detail": "GatewayClientRequestError: Browser control authentication was blocked because the local listener owner could not be verified."
    }
  ]
}

Diagnostics also report:

• Gateway endpoint 18789 is listening.
• Browser proxy host 18791 is not listening.
• node.invoke fails for browser.proxy.
• Missing browser proxy allowlist: none.

Expected result

The Windows Browser proxy host should start and allow the paired local WSL Gateway to invoke browser.proxy.

Additional note

A node reapproval request is pending, but it includes System commands even though System capability is intentionally disabled. The effective approved commands already include browser.proxy.

A sanitized diagnostics bundle is attached.

openclaw-diagnostics-20260905-130804.txt

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 5, 2026, 7:41 AM ET / 11:41 UTC.

Summary
Keep open: current main retains the reported rejection path, and browser-host provisioning remains unfinished. The related readiness work overlaps, but neither a fix nor the exact clean-install cause is established.

Reproducibility: unclear. for the full clean-install failure: source explains the exact error when browser-listener verification fails, but the Windows/WSL scenario and attachment remain unverified. No builds or tests were run during this read-only review.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Next step
Coordinate diagnosis with #1154; unresolved WSL host state and the credential boundary make automatic repair unsafe.

Security
None.

Review details

Best possible solution:

Distinguish absent and untrusted browser hosts, and provide an in-app Doctor/Fix action that restores a verified endpoint without relaxing credential protections.

Do we have a high-confidence way to reproduce the issue?

Unclear for the full clean-install failure: source explains the exact error when browser-listener verification fails, but the Windows/WSL scenario and attachment remain unverified. No builds or tests were run during this read-only review.

Is this the best way to solve the issue?

Unclear until host absence is distinguished from rejected ownership; preserving detailed provenance outcomes is a narrower starting point than changing authentication policy.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The unavailable diagnostics leave missing browser-host startup, failed WSL ownership verification, and incomplete listener capture unresolved.
• The pending System-command reapproval has not been explained and should not be treated as the cause of an error returned from the already-invoked browser capability.

Codex review notes: model internal, reasoning high; reviewed against 305bb4ef5334.

Label changes

Label changes:

• add P0: The reported fresh-install flow leaves the only selected capability unusable, with recovery requiring technical configuration or commands.
• add impact:security: The failure occurs at the listener-ownership boundary that protects the saved gateway token from untrusted local processes.
• add impact:ux-release-blocker: Browser-only first use remains blocked after clean product setup, and current recovery guidance provides no in-app repair.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P0: The reported fresh-install flow leaves the only selected capability unusable, with recovery requiring technical configuration or commands.
• impact:ux-release-blocker: Browser-only first use remains blocked after clean product setup, and current recovery guidance provides no in-app repair.
• impact:security: The failure occurs at the listener-ownership boundary that protects the saved gateway token from untrusted local processes.

Evidence reviewed

What I checked:

• Verified checkout: The checkout is clean, origin identifies the target repository, and HEAD matches the supplied current-main revision. (305bb4ef5334)
• Concrete clean-install report: The captured issue body reports Companion 2026.7.1-3, Gateway 2026.6.34, successful pairing and effective browser.proxy approval, but no listener on browser-control port 18791. The only selected capability therefore remains unusable after the product's local-gateway installation flow.
• Error occurs before browser HTTP: ExecuteAsync returns the exact reported error when endpoint authorization rejects a request carrying a shared token, before SendAsync. This is distinct from gateway command approval or an HTTP authentication rejection. (src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs:80, 305bb4ef5334)
• Browser authorization collapses provenance outcomes: For managed WSL connections, App inspects the browser port and accepts only ExpectedManagedGateway. NoListener and UnknownListener consequently produce the same browser authentication error. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2326, 305bb4ef5334)
• Absent host versus relayless WSL: With an empty Windows listener snapshot, provenance checks whether the expected distro's gateway service owns the requested port. It returns NoListener if that check fails, but can accept verified relayless WSL ownership; an absent Windows listener alone cannot determine the cause. (src/OpenClaw.Connection/ManagedLocalGatewayPortProvenanceService.cs:380, 305bb4ef5334)
• Security invariant and diagnostic coverage: Existing tests require an unverified browser listener to receive no HTTP request. Provenance tests separately cover absent guest ownership and valid relayless ownership; these tests were inspected, not executed. (tests/OpenClaw.Shared.Tests/CapabilityTests.cs:963, 305bb4ef5334)

Likely related people:

• Scott Hanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Barbara Kudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[mietwagen26]

Additional finding:

After updating Windows Companion to 2026.7.1-4 and OpenClaw Gateway to 2026.9.3, the issue still persists:

Browser control authentication was blocked because the local listener owner could not be verified.

The Companion log reports:

needsDaclAugmentation=True

and explicitly recommends:

Run wxc-host-prep prepare-system-drive (elevated) to grant the minimal metadata ACEs.

However, the installed MXC directory contains only:

wxc-exec.exe
wslcsdk.dll

There is no wxc-host-prep.exe anywhere under the OpenClawTray installation directory.

Windows Node is paired, connected and approved, with browser/device/system capabilities.

Gateway is running normally on 127.0.0.1:18789.

No listener exists on 18791.

This suggests the Windows Companion package may be missing the required host-prep binary or host preparation step.

[andyhau]

I can reproduce this on a fresh OpenClaw 2026.9.4 install under WSL2, connected to the Windows Companion (v2026.9.3). The Windows node is paired, connected and approved; system and screen capabilities work correctly, but browser control fails with:

GatewayClientRequestError: Browser control authentication was blocked because the local listener owner could not be verified.

I also tested with OPENCLAW_EAGER_BROWSER_CONTROL_SERVER=1. In that case both ports are listening and are owned by the same openclaw-gateway PID:

127.0.0.1:18789 → openclaw-gateway PID 4162
127.0.0.1:18791 → openclaw-gateway PID 4162

curl -i http://127.0.0.1:18791/ successfully reaches the browser-control service and returns HTTP/1.1 401 Unauthorized, as expected without credentials.

However, openclaw browser status and openclaw browser doctor --json still fail with the listener-owner verification error.

So in this case 18791 is reachable and demonstrably owned by the same process as the Gateway, but OpenClaw's ownership/authentication check still rejects it. This appears reproducible independently of Chrome/CDP configuration.

[Saad-Itani]

I can reproduce this as well, including after testing the latest Windows Companion alpha.

My setup is the standard Windows Companion + app-managed WSL2 Gateway setup. I initially suspected the Chrome extension/pairing, but after troubleshooting the full path this appears to be the same browser.proxy / listener ownership issue described here.

Environment

• Windows 11 x64 (build 22631)
• Windows Companion: 2026.9.4-alpha.1
• Gateway: 2026.9.4
• WSL2 / app-managed OpenClawGateway
• Windows node: paired, connected and approved
• Browser capability enabled
• NodeBrowserProxyEnabled: true
• browser.proxy is approved/effective

Direct invocation:

openclaw nodes invoke \
  --node <redacted> \
  --command browser.proxy \
  --params '{"path":"/status","method":"GET"}' \
  --json

returns:

Browser control authentication was blocked because the local listener owner could not be verified.

Windows Companion port diagnostics show:

Gateway endpoint: 18789 listening · owner wslrelay
Browser proxy host: 18791 not listening

I independently confirmed that 127.0.0.1:18791 has no listener.

The official Chrome extension is successfully paired but reports:

Paired; relay unavailable

and its 127.0.0.1:18799 relay is also not listening.

The Gateway itself is healthy, the Windows node is connected, NodeBrowserProxyEnabled is explicitly set to true, and browser.proxy appears in the node's effective commands.

I upgraded the Windows Companion from stable 2026.9.3 to 2026.9.4-alpha.1 specifically to test whether the newer build resolved this, but the behavior is unchanged.

[telbus]

Update / correction: host-local browser control now works on this WSL2 Gateway.

Tested on OpenClaw 2026.9.4 with the agent browser tool, target: "host", profile: "openclaw":

• Navigation to https://example.com: ✅ ok
• DOM snapshot: ✅ ok

This corrects my earlier report that explicit target=host calls were also blocked. They now succeed when target: "host" is set explicitly on every call; choosing profile: "openclaw" alone doesn't pin the destination.

The remaining failure is the Windows node browser proxy (target=node / browser.proxy), which still hits the endpoint authorization error. Per feedback from the Discord support bot (Krill), that points to Windows node proxy authorization, not Linux listener ownership or Chromium startup.

[mietwagen26]

Hello, I’m following up on this issue, as the Browser control problem is still blocking me from using OpenClaw.

The issue was submitted on September 5 with a sanitized diagnostics bundle. Please let me know if you need any additional logs, diagnostic information, or help reproducing the issue on the affected Windows computer.

I have kept the current installation unchanged and have not approved the pending reapproval request because it includes System commands, while only Browser capability is intended to be enabled.

Thank you for looking into this.

[NERJ-1206]

I can reproduce this on OpenClaw Windows Companion v2026.9.4 (stable), Windows 11.

The Gateway is connected and listening on port 18789. Windows Node is online, and browser.proxy appears under approved commands. The browser proxy host on port 18791 is not listening.

The Control UI reports: “Browser control authentication was blocked because the local listener owner could not be verified.” Starting the managed browser then reports that no compatible browser was found, although Chrome and Edge are installed on Windows.

[neevaona]

I’m experiencing the same browser-control issue with Windows Companion 2026.9.4 and Gateway 2026.9.5 running in WSL.

The Windows node connects and pairs successfully. Node mode, System tools, and Browser control are enabled, and browser.proxy is listed as approved/effective.

Browser requests fail with:

Browser control authentication was blocked because the local listener owner could not be verified.
Diagnostics report no listener on Windows port 18791. A manual Windows PowerShell check also returned no listener. Get-Command openclaw,node -ErrorAction SilentlyContinue returned no results, so neither command is available on that PowerShell session’s PATH.

Restarting the Windows Companion did not resolve the issue. An explicit browser-start request also failed with the same ownership error.

Is the Companion expected to start its own browser proxy host with a WSL gateway, or is a separate Windows component required? Is there a supported workaround?