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

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.
• #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

Read docs/WINDOWS_NODE_ARCHITECTURE.md first, especially the unfinished browser-host installer/launcher notes. Trace the existing Browser Control diagnostics and first-request path, then verify local MCP and gateway-mediated success plus absent, unreachable, unauthenticated, and incorrectly SSH-forwarded states. Done means a concrete repair or explicit disablement is shown and capability guidance prevents repeated Gateway restarts.