Browser proxy should be ready-to-use or visibly blocked with a guided repair path

[RomneyDa]

Problem

Browser control requires a separately running browser-control host on Gateway port + 2. Current diagnostics explain some failure modes, but a normal user can still request a browser action, see no visible result, and watch the agent unsuccessfully troubleshoot or restart the Gateway.

Desired outcome

Browser control is either ready to use or clearly unavailable with a concrete in-app repair path.

Definition of done

• Run a preflight when Browser Control is enabled and before the first browser request.
• Distinguish absent, unreachable, unauthenticated, and incorrectly SSH-forwarded hosts.
• Offer a concrete repair action: start/install/configure the host, or explicitly disable the capability with a clear explanation.
• Supply concise capability-state guidance to chat/agent context so it does not repeatedly restart the Gateway to diagnose the same prerequisite.
• Add local MCP and gateway-mediated proof for success and each blocked state.

Related

• Browser-host installer/launcher is still explicitly unfinished in docs/WINDOWS_NODE_ARCHITECTURE.md.
• Tool containment testing + triage (camera, browser) #850 is the broader camera/browser containment tracking epic.
• PCMag report (Aug. 6, 2026): https://www.pcmag.com/opinions/microsoft-thinks-openclaw-is-the-future-of-windows-my-testing-says-otherwise

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 13, 2026, 4:22 PM ET / 20:22 UTC.

Summary
Keep this issue open: an active linked pull request explicitly owns the reported readiness gap, and the author is a repository member. Its required Windows and real-behavior proof is still pending.

Reproducibility: unclear. the issue describes concrete prerequisite failures, but no current-main runtime trace was available and repository command execution was blocked.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should OpenClaw’s supported browser-host recovery stop at actionable status guidance, or should it own start, install, or configuration actions for the separate browser-control host?	Ship guidance-only readiness: Keep the browser-control host externally managed, but make every unavailable state explicit with an actionable supported recovery path.

Why: The report requests concrete repair actions while the linked PR proposes readiness detection and guidance; choosing which host lifecycle operations core owns is a product and support-boundary decision.

Next step
The open linked pull request explicitly owns this implementation, so a separate repair PR would duplicate active work.

Review details

Best possible solution:

Settle the supported recovery boundary, then land the linked preflight and guided-status implementation only after current-head Windows MCP and gateway proof covers ready and each blocked state.

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

Unclear: the issue describes concrete prerequisite failures, but no current-main runtime trace was available and repository command execution was blocked.

Is this the best way to solve the issue?

Unclear: readiness preflight and guidance address the reported failure mode, but maintainers must choose whether core should also own browser-host lifecycle actions.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked PR has no reported current-head Windows, local MCP, gateway-mediated, or Command Center real-behavior proof yet.
• Repository inspection was blocked by sandbox infrastructure, so this review cannot independently confirm current-main ownership or the proposed diff.

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

Label changes

Label changes:

• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:linked-pr-open: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P1: A requested browser-control workflow can fail without a clear in-product recovery path.
• impact:ux-friction: The report describes users being left to repeated troubleshooting when a separate prerequisite host is unavailable.

Evidence reviewed

What I checked:

• Open implementation owner: The issue timeline cross-references open pull request fix: preflight browser proxy readiness #1157, whose body explicitly declares that it fixes this issue and describes readiness preflight, failure classification, and guidance. (fe81645cc6f1)
• Required proof remains pending: The linked PR reports that current-head local MCP, gateway-mediated browser proxy, Command Center, and native Windows validation are blocked or pending, so the issue is not yet demonstrably implemented on main. (fe81645cc6f1)
• Inspection infrastructure failure: Read-only repository inspection could not run because the execution sandbox failed before command execution with “bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted”; current source, history, VISION.md, and maturity scorecard were therefore not independently inspected.

Likely related people:

• RomneyDa: GitHub context identifies RomneyDa as the repository-member author of the issue and source of its requested browser-proxy recovery direction; local feature-history inspection was blocked. (role: repository-member reporter and likely decision contact; confidence: low; files: docs/WINDOWS_NODE_ARCHITECTURE.md)

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.