[SebTardif]

What Problem This Solves

browser.proxy talks to 127.0.0.1, but its HTTP client followed the process proxy. With HTTP_PROXY or ALL_PROXY set, the gateway bearer token was sent to that proxy.

User Impact

Browser control calls go straight to the local control port. Response size and redirects are unchanged from the previous client.

Why This Change Was Made

new HttpClient() uses the default proxy, and current .NET does not skip loopback unless NO_PROXY says so. A 1 MiB response cap and a redirect ban were tried and then removed, because they change existing control-host behavior and need a maintainer decision.

Evidence

Head f9c993c35202b35ed90dde4aaa0189199006395f. HTTP_PROXY and ALL_PROXY pointed at a local listener on 79259c3c. The production client, with no substitute handler, called a second listener on the control port. The call succeeded and the proxy accepted 0 connections. That client code is unchanged on this head.

browser-proxy direct gateway_port=56139 control_port=56141 proxy_port=56140 proxy_connections=0 ok=True

GatewayFixtureHost --browser-proxy started the built tray against a loopback fixture gateway that accepts the node role, with a control host on the gateway port plus 2. winnode --command browser.proxy --params {"path":"/tabs"} exited 0.

{"result":{"ok":true}}
browser-control requests=1 authorized=1

A gateway nodes invoke through the installed WSL gateway was not run.

On head 0b29606d23a41615caa2bf0ac8c19eaeffcfdb64, a live child with OPENCLAW_GATEWAY_FIXTURE=1 called FixtureLoopbackListenerOwner.IsOwnedByCurrentProcessParent, then BrowserProxyCapability.ExecuteAsync. The authorize callback was that owner method, not a stub that always denies. The bearer value was a local marker, not a gateway token. The assemblies were built from this worktree. The on-disk tray executable is older than this head, so this run did not launch that executable.

A different process listened on 127.0.0.1:63773. The child's parent was alive and was not that listener. The owner returned false. browser.proxy returned the owner block, and the listener accepted 0 connections.

The same pattern then ran while the parent process owned 127.0.0.1:63774. The listener pid and start time matched the parent, and the owner returned true. After that parent left the process table, a different process listened on 127.0.0.1:63775. The child could no longer open the old parent id. The owner returned false, browser.proxy returned the same block, and the replacement listener accepted 0 connections.

foreign port=63773 listener=37216 parent=4604 child=41292 fixture=True owned=False denyOk=False accepts=0
owned port=63774 listener=42372 parent=42372 child=42428 fixture=True owned=True
expired parent=42372 lookup=failed replacement=63775 listener=18680 owned=False denyOk=False accepts=0
denyError=Browser control authentication was blocked because the local listener owner could not be verified.

Change Type

• Bug fix
• Feature
• Refactor
• Docs or instructions
• Tests or validation
• Security hardening
• Chore or infrastructure

Scope

• Tray or WinUI UX
• Windows node capability
• Local MCP or winnode
• Gateway, connection, or pairing
• Setup or onboarding
• Permissions, privacy, or security
• Tests, CI, or docs

Required proof pools

• none: no tray page, installer, or WSL gateway path changed. The proof is a loopback control listener and a loopback proxy listener.

Validation

Head af5ad2d363fae7fff4ed58b476ba21dcf4714035 in worktree C:\Users\sebta\wt-wn-1628. This head merges origin/main 94006b3672a034983e80a78dafe311e24ba80cce, ignores a fixture send lock that the connection handler already disposed, and keeps the audio startup test block longer than the test's observation wait. On bd8b2d0b32149fd46f51095e09329d8e4ee80e17, CI failed PublishedVerifierEnforcesRecoveryAndModelPhaseTokens(blockModel: True) with ObjectDisposedException from SemaphoreSlim.Release in FixtureGatewayServer.CloseConnectionsAsync. On 03e039d8a6c39c25c7fc048e2bc7059e40ca1d03, the UI job failed StopDuringStartup_WaitsForInitializationThenCleansUp: Assert.False(stopTask.IsCompleted) saw True because the fake start block timed out at 2 seconds. OPENCLAW_REPO_ROOT was that worktree.

• ./build.ps1: exit 0
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore: 4267 passed, 33 skipped, 0 failed, total 4300
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore: 3996 passed, 0 failed, total 3996
• dotnet test ./tests/OpenClaw.WinNode.Cli.Tests/OpenClaw.WinNode.Cli.Tests.csproj --no-restore: 129 passed, 0 failed, total 129
• PublishedVerifierEnforcesRecoveryAndModelPhaseTokens: 2 passed
• CloseConnectionsAsync_ToleratesAConnectionHandlerThatDisposedItsSendLock: passed
• AudioPipelineFirstAudioTimeoutTests on af5ad2d363fae7fff4ed58b476ba21dcf4714035: 13 passed, 0 failed. The product build, Shared, and Tray counts above are from 03e039d8a6c39c25c7fc048e2bc7059e40ca1d03. This commit does not change those projects.

The fixture host keeps the browser-proxy control listener and also accepts main's session-mutation scenario and setup handoff. The merge does not change browser.proxy production code. GatewayFixtureIsolation now requires the fixture local data directory to match the legacy app-data root plus OpenClawTray.

On the earlier head f9c993c35202b35ed90dde4aaa0189199006395f: Connection FixtureLoopbackListenerOwnerTests 6 passed, RealNodeClient_FixtureAcceptsTheNodeRole 1 passed, and BrowserProxyProfileKeepsExecutionCapabilitiesOff 1 passed. RealNodeClient_FixtureAcceptsTheNodeRole is part of the Shared suite that passed on this head.

Real behavior proof

• Behavior or issue addressed: browser.proxy could send the gateway bearer token to the process HTTP proxy.
• Real environment tested: Windows 11, worktree C:\Users\sebta\wt-wn-f009, head f9c993c35202b35ed90dde4aaa0189199006395f.
• Exact steps or command run after this patch: HTTP_PROXY and ALL_PROXY pointed at a TcpListener on 127.0.0.1 on 79259c3c. On this head, GatewayFixtureHost --browser-proxy launched the built tray. winnode --list-tools included browser.proxy. winnode --command browser.proxy --params {"path":"/tabs"} called the fixture control host.
• Evidence after fix:

browser-proxy direct gateway_port=56139 control_port=56141 proxy_port=56140 proxy_connections=0 ok=True
{"result":{"ok":true}}
browser-control requests=1 authorized=1

The owner check rejects an unrelated listener, a parent id reused by a later process, a listener whose start time does not match the live parent, and an exited parent. BrowserProxy_UnverifiedListener_DoesNotSendTheRequest denies authorization and leaves the HTTP handler unused.

• Observed result after fix: The direct control call did not touch the process proxy. The MCP call returned ok: true. The fixture host owned the control port and recorded one authorized request. The token was not printed. A denied owner check does not send a request.
  On head 0b29606d23a41615caa2bf0ac8c19eaeffcfdb64, the live child above is the current-head owner trace. A foreign loopback listener was rejected before HTTP (accepts=0). A live parent that owned the listener was accepted (owned=True). After that parent exited, the replacement listener was rejected before HTTP (accepts=0).

• What was not tested: A gateway nodes invoke through the installed WSL gateway was not run. The tray browser page was not opened. The direct-proxy listener proof was collected on 79259c3c. That client code is unchanged on this head. This session did not relaunch the built tray. Exact parent-id reuse was not forced. The expired case is the parent process disappearing while another process owns the port. The live owner trace above was collected on 0b29606d23a41615caa2bf0ac8c19eaeffcfdb64.

• Screenshot or artifact links verified? N/A

Security Impact

• New permissions or capabilities? No
• Secrets or tokens handling changed? Yes
• New or changed network calls? No
• Command or tool execution surface changed? No
• Data access scope changed? No
• If any answer is Yes, explain the risk and mitigation: The gateway bearer token is still sent to the loopback browser-control port. It is no longer sent through HTTP_PROXY or ALL_PROXY.

Compatibility and Migration

• Backward compatible? Yes
• Config or environment changes? No
• Migration needed? No

Review Conversations

• I replied to or resolved every bot review conversation addressed by this PR.
• I left unresolved only conversations that still need maintainer judgment.

On head f9c993c, GatewayFixtureHost --browser-proxy-foreign bound port 53646 in a child process. The tray parent was the host. winnode --command browser.proxy returned exit 1: Browser control authentication was blocked because the local listener owner could not be verified. The child count file stayed at requests=0, so no socket was accepted and no token was sent. The installed WSL gateway service last exited 78, and doctor --fix is not used, so a nodes invoke on that gateway was not run.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs changes before merge.

What this changes

This PR bypasses the process proxy for browser-control requests and adds isolated fixture coverage.

Example: HTTP_PROXY points to 127.0.0.1:56140 while browser control listens on 127.0.0.1:56141.

• Before: The default HTTP client can send the bearer-bearing browser-control request through the proxy.
• After: The production client reaches the control listener directly, with zero proxy connections.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The focused production fix has applicable real transport and MCP proof; the latest regression hardening lacks reported execution, while merge conflicts remain a separate workflow blocker.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (live_output): Supplied Windows live output exercises the real HTTP client with zero proxy connections and the built tray through winnode discovery and invocation; foreign and expired-parent listeners receive no request, and the proved production client and owner-check blobs remain unchanged.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Product

Kind: Bug fix · Worth it: Yes · Fix scope: Complete
User problem: Browser-control requests can expose the shared gateway token to the configured process HTTP proxy.
Reason: Direct loopback routing restores the local credential boundary; the added flags select developer fixture scenarios rather than new installed-app policy.

Merge readiness

⛔ Needs changes before merge - 1 item remains

Keep open: current main still needs the direct browser-control transport fix, and no discrete introduced defect was found; GitHub reports a merge conflict that blocks landing.

Priority: P2
Reviewed head: c2ac9503f1185f8f9b68a50425504c4b032c52c5

Before merge

• Complete next step - Resolve GitHub's reported merge conflict, then validate the resulting head with the required build, Shared, Tray, and CLI suites plus the focused proxy and fixture-startup regressions.

Findings

None.

Tests

• Missing end-to-end proof: Execution demonstrating base failure and head success for the newly hardened proxy and startup-cleanup regressions is not supplied.

Agent review details

How this fits together

The shared browser capability receives node or MCP commands, authorizes the local browser-control endpoint, sends authenticated HTTP requests, and returns browser results.

flowchart LR
  A[Gateway node command] --> C[Browser capability]
  B[Local MCP command] --> C
  C --> D[Endpoint authorization]
  D --> E[Direct HTTP client]
  E --> F[Loopback browser control]

Loading

Technical review

Best possible solution:

Land the direct transport fix with the existing endpoint authorization and fixture isolation preserved.

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

Current-main source constructs a proxy-aware client and attaches the bearer token; supplied Windows transport observations support the reported path, but this review executed no reproduction.

Is this the best way to solve the issue?

Disabling proxy use in the shared browser-control client addresses the cause directly, and the additional fixture switches exercise the existing command without introducing a product setting.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 69276a1bcca5.

Provenance checked

• Browser-control HTTP transport keeps the original intent (ff92351: The original bridge targets a local browser-control host; no explicit intent to route its credentials through a process proxy was found.)
• Browser endpoint authorization keeps the original intent (fix: local gateway connections recover after listener or token drift #1053: Verify listener ownership before sending stronger credentials and exclude unmanaged or ambiguous ordinary endpoints.)
• Gateway fixture profile, protocol, and process ownership keeps the original intent (feat: explore and test the app without a live Gateway #1439: Exercise the real app through synthetic Gateway data while owning each run's credentials, profile, ports, and processes.)
• MCP discovery guidance keeps the original intent (Update WinNode CLI live tool discovery #525: Document live tool discovery and the CLI's local bearer-token contract.)
• Audio startup test blocking keeps the original intent (Fix silent WASAPI capture startup hang #1123: Characterize bounded audio startup and lifecycle races through deterministic capture seams.)

Testing

Proof path: shipped entry point.

Security

None.

Evidence

What I checked:

• Current main still needs the fix: Fetched main constructs a default proxy-aware HttpClient, then attaches the shared gateway bearer token to browser-control requests. (src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs:52, 69276a1bcca5)
• Pinned production change: The introduced diff sets SocketsHttpHandler.UseProxy=false while preserving endpoint resolution, authentication retry, redirects, response handling, and saved settings. (src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs:52, c2ac9503f118)
• Applicable real behavior proof: The supplied body, source revision 274331cff29b7683a586f88095394c36e062a25972916ba4bb9a7ddb7c3826b2, records direct production-client output with proxy_connections=0, built-tray MCP discovery and invocation, and rejection of foreign and expired-parent listeners before socket acceptance. The production capability and listener-owner blobs are identical between the proved head and reviewed head. (src/OpenClaw.Connection/FixtureLoopbackListenerOwner.cs:16, c2ac9503f118)
• Credential boundary preserved: The fixture exception requires explicit valid fixture mode and a live parent whose identity matches the loopback listener; ordinary managed-local and SSH ownership checks remain intact, consistent with fix: local gateway connections recover after listener or token drift #1053. (src/OpenClaw.Tray.WinUI/App.xaml.cs:2409, c2ac9503f118)
• Latest regression hardening: The latest commit isolates proxy tests in child processes with a default-handler negative control and makes fixture startup retain cleanup ownership until resources transfer successfully. (tests/OpenClaw.GatewayFixtureHost/GatewayFixtureRun.cs:351, c2ac9503f118)
• Verified merge blocker: GitHub reports mergeable=false and mergeable_state=dirty for the reviewed head; no local synthetic merge was used to infer deletions. (c2ac9503f118)

Likely related people:

• Scott Hanselman: Raw commit ff92351 adds src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs:37 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: ff923514afa1; files: src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs)
• Barbara Kudiess: Raw commit bc210e0 adds src/OpenClaw.Tray.WinUI/App.xaml.cs:2245 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: bc210e048aa9; files: src/OpenClaw.Tray.WinUI/App.xaml.cs)
• anagnorisis2peripeteia: Raw commit a2e2773 adds src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs:34 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: medium; commits: a2e2773bb935; files: src/OpenClaw.Shared/Capabilities/BrowserProxyCapability.cs)

Labels

Label changes:

• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.
• remove status: 👀 ready for maintainer look: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: This fixes a concrete credential-routing defect when a process proxy is configured, without evidence of an urgent deployment incident.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action.
• proof: sufficient: Contributor real behavior proof is sufficient.

Rating scale

6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior.

Workflow

ClawSweeper edits this one comment on every review. Comment @clawsweeper re-review for a fresh review only. Repair and merge execution lanes are retired.

History

Review history (16 earlier review cycles; latest 8 shown)

• reviewed 2026-10-05T18:11:23.698Z sha 8d29baa :: needs real behavior proof before merge. :: none
• reviewed 2026-10-05T18:28:41.182Z sha 0b29606 :: needs real behavior proof before merge. :: none
• reviewed 2026-10-06T06:34:12.928Z sha 0b29606 :: needs changes before merge. :: none
• reviewed 2026-10-07T09:06:34.005Z sha 0b29606 :: needs changes before merge. :: none
• reviewed 2026-10-07T09:58:02.655Z sha bd8b2d0 :: needs maintainer review before merge. :: none
• reviewed 2026-10-07T10:28:12.069Z sha 03e039d :: needs maintainer review before merge. :: none
• reviewed 2026-10-07T10:59:32.989Z sha af5ad2d :: needs maintainer review before merge. :: none
• reviewed 2026-10-08T15:39:04.132Z sha 027996f :: needs maintainer review before merge. :: none

Reviewed October 20, 2026, 2:12 AM ET / 06:12 UTC (Revision 17).

[karkarl]

Global triage: HOLD_FOR_AUTHOR. Take confidence 20%; recommendation confidence 98%; effort medium; risk high.

Reviewed exact head 027996faa892. GitHub currently reports CLEAN with 24 passing, 0 failing, and 0 pending checks. proof label is sufficient. Durable automated signal: Codex review: needs maintainer review before merge..

Author: resolve the current durable review findings, add focused regressions, and request a fresh exact-head review.

This is a triage classification, not a merge action. No branch changes were made.