openclaw-windows-node/docs/MISSION_CONTROL.md

Mission Control: Topology-Aware Command Center Plan

This plan turns the Windows tray from a "connected/not connected" companion into a Mission Control surface for any OpenClaw gateway topology. It is based on a deep audit of:

• Current Windows code in this repository on mission-control-audit.
• Current upstream Mac app code in openclaw/apps/macos/Sources/OpenClaw.
• Current upstream gateway, node policy, browser proxy, health, presence, usage, pairing, and discovery code in openclaw/src and openclaw/extensions.

The main product decision is deliberate: do not make a native Windows gateway the center of gravity. The Windows app should be a first-class node and command center for any OpenClaw gateway: Mac over SSH tunnel, WSL, Windows Node.js, LAN, Tailscale, or unknown/remote.

1. Goals

1. Make the Windows tray explain what it is connected to: local gateway, WSL gateway, Mac via SSH tunnel, Tailscale/LAN gateway, or unknown remote.
2. Reach deeper Mac parity by porting the valuable Mac "mission control" ideas, not just matching command names.
3. Keep OpenClaw open and topology-neutral: the tray should observe, classify, diagnose, and repair; it should not force one gateway hosting model.
4. Prioritize privacy and safety. Diagnostics must not trigger camera, screen recording, microphone, or broad command execution.
5. Make every repair action copyable, explainable, and topology-aware.

2. Audit findings

2.1 Windows current state

Windows now has a strong foundation:

• Node Mode with canvas, camera, screen snapshot/record, location, device info/status, system commands, notifications, and exec approval policy.
• Command Center status detail window with channels, sessions, usage, local/operator node inventory, allowlist diagnostics, pairing warnings, and activity stream.
• SSH tunnel settings and service.
• Activity Stream and support-bundle copy path that avoid storing invoke payloads.
• Deep links including openclaw://commandcenter.

The biggest missing model is not another gateway implementation. It is topology state. Current settings collapse all topologies into:

• GatewayUrl
• UseSshTunnel
• SSH host/user/ports
• EnableNodeMode

There is no first-class concept of "Mac over SSH", "WSL", "Windows native", "Tailscale", "LAN", or "unknown".

2.2 Mac Mission Control behaviors worth porting

The Mac app is not just a menu bar icon. It is a gateway/node/control-plane cockpit.

Important Mac surfaces:

• Status icon with activity badge and gateway error dot.
• Hover HUD with current status and last tool/activity.
• WebChat, Canvas, Settings, Onboarding, Agent Events, Notify Overlay, Voice/Talk overlays.
• Menu sections for sessions, usage, cost, nodes, gateway discovery, channel state, browser control, camera/canvas/voice toggles, exec approvals, debug actions, and update status.
• Per-session submenus with preview, thinking/verbose settings, reset, compact, delete, and log opening.
• Per-node submenus with copy actions for node ID, name, IP, platform, versions, caps, and commands.
• Channel settings driven by gateway schemas and channel health/probe details.
• Debug/diagnostic actions: health check, test heartbeat, open logs, open config, open session store, restart gateway, reset SSH tunnel, port diagnostics, kill process by PID, rolling JSONL diagnostics, and verbose logging.

Important Mac gateway lifecycle pieces:

• GatewayProcessManager state machine: stopped, starting, running, attachedExisting, failed.
• Attach-existing path before spawning a gateway.
• GatewayEnvironment: Node runtime, OpenClaw CLI location/version, port/bind resolution.
• PortGuardian: identifies listeners on gateway ports, classifies expected vs unexpected processes, and can kill with confirmation.
• GatewayEndpointStore: async-stream state for local/remote/unconfigured endpoint readiness.
• Gateway discovery via Bonjour/SRV plus Tailscale selection rules.
• Remote SSH tunnel actor with robust SSH options, fast-fail check, random local port fallback, and tunnel reuse across app restarts.
• Control channel with friendly error mapping and recovery scheduling.
• Presence reporter every 180 seconds with host/IP/mode/version/platform/device fields.

Important Mac security/privacy pieces:

• Permission matrix for notifications, automation, accessibility, screen recording, microphone, speech, camera, and location.
• Onboarding security banner warning that agents can run commands, read/write files, and capture screenshots.
• Exec approval UX with Deny / Allow Once / Allow Always.
• Command display sanitizer for control chars, invisible characters, and non-ASCII spaces to prevent spoofing.
• Glob allowlist matcher semantics.
• Host environment sanitizer with large inherited secret/toolchain blocklist, PATH override rejection, and shell-wrapper allowlist.
• Exec approval edits with base-hash optimistic concurrency: implemented for system.execApprovals.get/set; stale remote writes are rejected
• Pairing prompt with name, node ID, platform, app, IP, and approve/reject/later actions.

2.3 Gateway and browser proxy findings

browser.proxy is the main concrete remaining Mac node command gap.

Gateway/browser facts:

• browser.proxy is a canonical node command and included in Windows platform defaults at the gateway policy level.
• Gateway policy still requires both gates:
  • command allowed by platform defaults or gateway.nodes.allowCommands
  • command declared by the node
• The browser plugin/node-host contract is:
  • input: method, path, optional query, body, timeoutMs, profile
  • default timeout: 20 seconds
  • output: { result, files? }
  • files are base64 payloads with path/mime metadata
• Persistent profile mutations are blocked at gateway and node-host levels.
• Mac implements browser.proxy only for local mode, proxying to 127.0.0.1:{gatewayPort+2} with Bearer or x-openclaw-password auth, and a 10 MB/file extraction cap.
• Windows managed SSH tunnel mode now forwards both the gateway port and the browser-control companion port (local+2 to remote+2) when the browser proxy capability is enabled, so Mac-over-SSH topologies can satisfy the same local-only browser proxy contract.

Gateway APIs and signals worth surfacing:

• hello-ok snapshot/policy fields, including tick interval and limits.
• health, presence, tick, status, system-presence, sessions.*, usage.status, usage.cost, sessions.usage*, node.list, node.describe, pairing APIs, and config/wizard APIs.
• Snapshot fields such as presence, health, stateVersion, uptimeMs, auth/session defaults.
• Non-loopback gateway security expectations: use wss, auth/trusted proxy, and explicit Control UI origins.
• Discovery signals: mDNS/SRV, wide-area DNS-SD, Tailscale modes.

3. Topology model

3.1 Gateway kinds

Initial enum:

Kind	Meaning	Detection signals
MacOverSsh	Localhost URL backed by an SSH tunnel to a Mac/remote host	UseSshTunnel=true, localhost gateway URL, SSH host present; future: presence platform macOS
Wsl	Gateway likely running in WSL2	localhost URL without tunnel, wsl.exe available, port/listener/process hints indicate WSL
WindowsNative	Gateway likely running directly on Windows	localhost URL without tunnel and no WSL evidence
Tailscale	Gateway reached via Tailscale DNS/IP	host ends .ts.net or IP is in 100.64.0.0/10
RemoteLan	Gateway reached via LAN/mDNS/private host	RFC1918 IP, .local, or non-loopback private hostname
Remote	Public/unknown non-local remote gateway	non-loopback public host
Unknown	Cannot classify	invalid/missing URL or conflicting settings

3.2 State objects

Additive shared models:

public enum GatewayKind
{
    Unknown,
    WindowsNative,
    Wsl,
    MacOverSsh,
    Tailscale,
    RemoteLan,
    Remote
}

public enum TunnelStatus
{
    NotConfigured,
    Stopped,
    Starting,
    Up,
    Restarting,
    Failed
}

public sealed class GatewayTopologyInfo
{
    public GatewayKind DetectedKind { get; set; }
    public string DisplayName { get; set; }
    public string GatewayUrl { get; set; }
    public string Host { get; set; }
    public bool UsesSshTunnel { get; set; }
    public string Transport { get; set; }
    public string Detail { get; set; }
}

public sealed class TunnelCommandCenterInfo
{
    public TunnelStatus Status { get; set; }
    public string LocalEndpoint { get; set; }
    public string RemoteEndpoint { get; set; }
    public string? Host { get; set; }
    public string? User { get; set; }
    public string? LastError { get; set; }
    public DateTime? StartedAt { get; set; }
}

Extend GatewayCommandCenterState with:

public GatewayTopologyInfo Topology { get; set; } = new();
public TunnelCommandCenterInfo? Tunnel { get; set; }

3.3 Classifier rules

Phase 1 classifier should be pure and unit-testable:

1. If UseSshTunnel is true and SSH host is set:
   • if gateway URL host is localhost/127.0.0.1/::1, classify MacOverSsh for now.
   • if SSH host ends .ts.net, include "over Tailscale SSH" in detail but keep tunnel as the primary transport.
2. Else if gateway URL host is localhost/127.0.0.1/::1:
   • classify WindowsNative initially.
   • a later WSL probe can refine to Wsl.
3. Else if host ends .ts.net or IP is in 100.64.0.0/10:
   • classify Tailscale.
4. Else if host is RFC1918, .local, or common private names:
   • classify RemoteLan.
5. Else if host is non-empty:
   • classify Remote.
6. Else:
   • classify Unknown.

Phase 2 WSL refinement:

• Probe wsl.exe -l -q with a short timeout.
• Optional port/process detection should be cached and never block UI.
• If localhost gateway is connected and WSL evidence is strong, classify Wsl.

4. Command Center UX target

4.1 Gateway/topology header card

Add a top card under the current status header:

• "Gateway: Windows native / Mac over SSH / WSL / Tailscale / LAN / Remote / Unknown"
• URL host and transport: ws, wss, ssh tunnel, tailnet, lan
• tunnel state if configured: Up, Restarting, Failed, Stopped
• last health timestamp and gateway version/uptime once available from protocol

4.2 Diagnostics categories

Add categories beyond current node/channel/allowlist/parity:

Category	Examples	Repair action
topology	Localhost URL but no local/tunnel evidence; remote plaintext ws://; unknown public host	Explain expected topology; copy URL/settings hints
tunnel	SSH tunnel stopped/restarting/failed	Copy ssh -N -L ... command; "Reset tunnel" later
wsl	Localhost likely backed by WSL; NAT or distro reboot may break it	Show WSL-specific diagnostic hints
tailscale	Tailnet host but no tunnel/direct auth mismatch	Show Tailscale/wss/auth hints
browser	browser.proxy disabled, policy-filtered, or missing a gateway+2 browser-control host	Explain Settings, allowlist, SSH forward, or local browser-host repair path
gateway	stale health/stateVersion, auth error, not connected	Existing patterns plus topology-specific detail

4.3 Tray menu badge

Add a small topology badge next to status:

• "Gateway: Connected - Mac over SSH"
• "Gateway: Connected - Windows native"
• "Gateway: Connected - Tailscale"

4.4 Settings hint

In Settings, show read-only detected topology near gateway URL/tunnel settings: implemented with a live summary under the topology guide

• detected kind
• whether settings imply tunnel/direct
• warning if URL/tunnel conflict

4.5 Future Mission Control pages

Keep HubWindow as the Command Center host, with pages/sections for:

1. Overview
2. Gateway topology
3. Tunnel/transport
4. Channels
5. Sessions
6. Nodes/capabilities
7. Command policy/allowlist
8. Pairing/devices
9. Activity/events
10. Permissions/privacy
11. Logs/debug/repair

5. Mac parity matrix

5.1 Node command surface

Command area	Mac status	Windows status	Priority
Canvas core	Present	Mostly present	Verify defaults, payload names, A2UI bridge, snapshot shape
Screen snapshot	Present	Present	Verify defaults: max width, format, quality, metadata
Screen record	Present	Present	Verify clamps/audio fields; do not live-test without permission
Camera list/snap/clip	Present	Present	Verify facing/deviceId/delay/default quality
Location	Present	Present	Align error tokens and permission mode
Device info/status	Present	Present	Done; keep payload shape tests
System notify	Present	Present	Add overlay/priority parity later
System run/which	Present	Present	Verify push event names and approval reasons
Exec approvals get/set	Present	Present	Base-hash optimistic concurrency implemented
Browser proxy	Present, local-only	Local bridge present; live smoke blocked until browser-control host listens on gateway+2	Continue host setup/live-smoke guidance

5.2 Mission Control surfaces

Mac capability	Windows today	Plan
Gateway process state	Implemented for detected/managed runtimes	Command Center shows topology, gateway listener process/PID, and managed/detected SSH context; process manager remains only for a future owned local Windows gateway
Endpoint store/discovery	Implemented first slice	Settings topology presets and detected topology summaries classify local, SSH, WSL, and remote gateway shapes
SSH tunnel robust state	Implemented	Managed SSH tunnel status/error/runtime details surface in Settings, Command Center, support context, and restart actions
PortGuardian	Partial	Read-only port diagnostics identify local listeners and owning process/PID; destructive kill actions remain intentionally absent
HealthStore derived states	Implemented first slice	Command Center warnings include topology-aware gateway, tunnel, browser-control, channel, usage, and node health
Nodes submenu copy actions	Implemented	Per-node copy and full node inventory copy include command groups, filtered commands, disabled settings, and parity gaps
Session previews/settings	Implemented	Tray session rows include previews plus thinking/verbose, reset, compact, and delete actions
Cost 30-day chart	Implemented	Command Center renders 30-day cost bars from usage.cost daily totals
Agent events ring	Implemented	Activity Stream keeps a 400-event rich ring and support bundle window
Permissions matrix	Implemented first slice	Command Center shows safe Windows privacy settings deep links without probing devices
Onboarding security banner	Implemented	Setup Wizard warns about agent control of enabled local command/screen/camera/location/browser/canvas surfaces
Debug actions	Implemented	Tray, Command Center, deep links, and PowerToys expose logs/config/diagnostics, health/update actions, managed SSH restart, support context, debug bundle, browser setup, and copyable diagnostics/summaries
Voice/Talk	Missing	Separate roadmap track
Cron/Skills settings	Missing/limited	Separate roadmap track

6. Browser proxy feasibility

6.1 What it is

browser.proxy is not a generic HTTP proxy. It is a node command that forwards browser-plugin requests through a node-host endpoint and returns structured results and optional extracted files.

6.2 Windows options

1. Local gateway/browser-host proxy parity

   • Implement only when gateway is local or tunnel-local.
   • Proxy to 127.0.0.1:{gatewayPort+2} like Mac.
   • Use Bearer/token or password header as gateway expects.
   • Enforce same method/path/query/body/timeout/profile contract.
   • Enforce same persistent-profile mutation block and file-size cap.
   • Best Mac parity, but depends on browser plugin host availability on Windows.

2. Edge/WebView2 DevTools bridge

   • Use WebView2/Edge DevTools protocol from the tray.
   • More Windows-native, but diverges from gateway browser extension contract.
   • Riskier and likely not the immediate parity path.

3. Do not implement in tray; require browser extension node-host

   • Keep tray focused on desktop node and command center.
   • Command Center explains why browser.proxy is absent and how to install/enable the browser plugin.
   • Lowest risk, but leaves a Mac command gap.

Recommended: investigate option 1 first, with browser.proxy gated to local/tunnel topologies and disabled for remote public gateways unless the upstream browser host contract says otherwise.

Current Windows implementation status: Windows node now advertises browser.proxy and forwards it to the local browser control host at 127.0.0.1:{gateway port + 2}. It uses the gateway bearer token first and retries with the same shared secret as browser-host password/basic auth if bearer auth is rejected. Managed SSH tunnel mode also forwards the companion browser-control port (local gateway port + 2 to remote gateway port + 2) when the browser proxy capability is enabled. Command Center still performs the read-only feasibility probe and warns when no compatible local browser host is listening, because the command depends on that local service being available.

7. Security and privacy requirements

1. Diagnostics must never take screenshots, record screen, capture camera, start microphone, or run arbitrary commands.
2. Support bundles must not include base64 payloads, tokens, screenshots, recordings, camera data, or command arguments.
3. Browser proxy must be local-only until we prove remote behavior is safe and intended.
4. Exec approval UI must include command display sanitization before adding "Allow Once/Always" UX.
5. Environment override parity should reject PATH and dangerous inherited/override keys.
6. Pairing approvals must show identity, platform, app, IP, and repair status before approval.
7. Allowlist repair should distinguish safe commands from privacy-sensitive commands. This is already in the Windows Command Center and should remain a product rule.

8. Implementation phases

Phase 1: Topology model and gateway card

Files:

• src/OpenClaw.Shared/Models.cs
• src/OpenClaw.Shared/SettingsData.cs if optional declared kind is persisted
• src/OpenClaw.Tray.WinUI/App.xaml.cs
• src/OpenClaw.Tray.WinUI/Services/SshTunnelService.cs
• src/OpenClaw.Tray.WinUI/Windows/HubWindow.xaml
• src/OpenClaw.Tray.WinUI/Windows/HubWindow.xaml.cs
• tests/OpenClaw.Shared.Tests/ModelsTests.cs
• tests/OpenClaw.Tray.Tests/SettingsRoundTripTests.cs if settings change

Deliverables:

• GatewayKind, TunnelStatus, GatewayTopologyInfo, TunnelCommandCenterInfo.
• Pure topology classifier.
• Tunnel state/error/startedAt from SshTunnelService.
• Gateway card in Command Center.
• Topology/tunnel warnings.

Risk: low. No protocol changes.

Phase 2: Better tunnel and WSL diagnostics

Deliverables:

• Mac-equivalent SSH options: implemented for tunnel startup
  • BatchMode=yes
  • ExitOnForwardFailure=yes
  • ServerAliveInterval=15
  • ServerAliveCountMax=3
  • TCPKeepAlive=yes
• Explicit tunnel states (NotConfigured, Stopped, Starting, Up, Restarting, Failed): implemented
• Fast-fail detection.
• Optional random local port fallback.
• WSL detection helper with timeout/cache. Explicit wsl.localhost / .wsl host classification is implemented.
• Tunnel reset action.

Risk: medium. Process lifecycle and port behavior need careful tests.

Phase 3: Gateway self and presence model

Deliverables:

• Parse hello-ok snapshot/version/policy fields: implemented
• Parse/preserve presence events.
• Show gateway version, uptime/stateVersion, auth source, presence count: implemented in Command Center gateway card
• Add node/presence freshness warnings.

Risk: low-medium; mostly parsing and UI.

Phase 4: Mac-like diagnostics and repair

Deliverables:

• Debug/Mission Control actions:
  • open log: implemented as Open Logs folder
  • open config folder: implemented
  • open session store
  • run health now: implemented as Refresh Health
  • send test heartbeat
  • reset managed SSH tunnel: implemented as Restart SSH Tunnel when Settings owns the tunnel
  • restart local gateway if topology is WindowsNative and managed
  • copy privacy-safe support context: implemented
• Rolling diagnostics JSONL with rotation: implemented for privacy-safe app/connection/gateway/tunnel metadata
• Port diagnostics table: read-only local listener visibility implemented, including owning PID/process name when Windows exposes it
• Manual SSH tunnel detection: implemented Command Center classification for loopback gateway ports owned by ssh, so hand-started local forwards are not mislabeled as native Windows gateways
• Gateway runtime owner summary: implemented in Command Center topology/support context so local gateway or SSH-forward listener process name, PID, and port are visible without managing the process
• Browser proxy SSH forward warning: implemented targeted Command Center guidance when an SSH tunnel gateway is up but the companion gateway port + 2 browser-control forward is missing
• Browser proxy invoke error guidance: implemented browser.proxy unreachable/timeout errors that name 127.0.0.1:{gateway+2} and show the exact SSH local-forward shape
• Settings SSH browser-forward guidance: implemented Settings copy explaining that the managed SSH tunnel forwards local-port+2 to remote-port+2 for browser.proxy when the browser proxy bridge is enabled
• Settings SSH test tunnel parity: implemented temporary Settings test tunnels with the same optional browser-control local+2 forward runtime uses when Browser proxy bridge is enabled
• Settings SSH tunnel preview: implemented selectable Settings preview of the exact managed ssh -N -L ... command, including the optional browser-control companion forward
• Browser proxy disabled guidance: implemented a specific Command Center warning/copy hint when browser.proxy is intentionally disabled in Settings
• Asymmetric SSH browser guidance: fixed Command Center and browser.proxy invoke guidance so local gateway+2 and remote gateway+2 can differ
• SSH local browser-port source: fixed Command Center browser diagnostics to derive the local browser-control port from the active tunnel local endpoint instead of stale saved gateway URLs
• Browser-control host runtime smoke: verified the upstream browser-control host can listen locally on 127.0.0.1:{gateway+2}, return HTTP 200 from / and /tabs, and appear in Command Center port diagnostics with owning PID/process
• Browser proxy auth guidance: implemented warnings for QR/bootstrap-paired Windows nodes that advertise browser.proxy without a saved gateway shared token, and clarified invoke errors for missing versus mismatched browser-control auth

Risk: medium-high for kill/restart actions; start as read-only/copy actions.

Phase 5: Node command byte-for-byte parity audit fixes

Deliverables:

• Verify and align canvas/screen/camera/location/system payload defaults and error tokens.
• Verify push event names for exec.
• Add missing base-hash concurrency semantics if needed: implemented for remote exec approval policy edits
• Add browser.proxy feasibility prototype or explicit "not implemented" install guidance: local browser-control bridge implemented; host runtime and Command Center listener detection smoke-tested; remaining end-to-end invoke blocker is matching operator/gateway auth for the active gateway

Risk: varies; browser.proxy is medium-high.

Phase 6: Security/privacy UX parity

Deliverables:

• Windows permission matrix with deep links:
  • camera
  • microphone
  • location
  • notifications
  • broad file system access if relevant
  • screen capture/graphics capture guidance
  • First read-only Command Center slice is implemented. It surfaces these settings pages and explanatory rows, but intentionally does not query, request, or exercise device permissions.
  • Capability diagnostics copy is implemented for declared commands, gateway allowlist status, and privacy-sensitive opt-ins.
• Mac-style onboarding security warning: implemented in Setup Wizard Node Mode step, warning users that approved agents can run local commands and access enabled screen/camera/location/browser/canvas surfaces
• Topology choice onboarding: first Settings guide implemented with local, WSL, SSH tunnel, and remote/Tailscale presets
• Exec approval dialog with sanitizer and three-button flow: implemented for local Prompt policy decisions with Allow once / Always allow / Deny
• Exec approval remote-policy hardening: implemented guardrails so system.execApprovals.set cannot remotely switch to default allow, install broad/dangerous allow rules, or overwrite a newer local policy without a matching baseHash
• Host env sanitizer parity hardening: implemented expanded blocking for secret-looking overrides such as tokens, passwords, API keys, access keys, private keys, client secrets, and connection strings
• Dangerous command opt-in guidance: implemented copyable safety guidance for camera/screen privacy-sensitive commands without emitting one-click dangerous repair commands
• Node capability settings: implemented Settings toggles for canvas, screen, camera, location, and browser proxy command groups so privacy-sensitive surfaces can be disabled before reconnecting/re-pairing
• Disabled capability diagnostics: implemented Command Center distinction between intentionally disabled Settings groups and true gateway allowlist/parity gaps
• Browser proxy policy diagnostics: implemented a specific Command Center warning/copy action for declared browser.proxy commands filtered by gateway policy, instead of burying them under generic blocked-command output

Risk: high for exec/security. Do not rush.

Phase 7: Mission Control depth

Deliverables:

• Session previews with thinking/verbose controls.
• Cost 30-day bars: implemented in Command Center from usage.cost daily totals
• Node copy submenus / summaries: implemented first Command Center copy action
• Channel health summary and copyable context: implemented first summary plus Command Center start/stop actions
• Channel schema forms and QR login flows: implemented first Windows surface with channel setup/dashboard deep links and copyable channel context
• Skills/Cron settings: implemented first Windows surface with Command Center dashboard entrypoints and copyable guidance
• Agent events ring expansion: implemented first Command Center recent-activity panel with copy/open-stream actions
• Hover HUD / richer tray tooltip: implemented with topology, channel, node, warning, and activity summary
• Update status: implemented in Command Center support/debug section and copied support context, including current version, latest prompted version when known, and last check outcome

Risk: medium; mostly UI and gateway method plumbing.

Phase 8: Optional local Windows gateway convenience

This is optional and should not block Mission Control.

Deliverables:

• Detect existing local Windows gateway.
• Attach to it and show logs/version/port.
• Only if user opts in: start/stop/restart a managed local gateway.

Risk: high. Requires Node/runtime/version/process ownership. Keep separate from topology-aware Command Center.

9. Test strategy

Unit tests

• Topology classifier matrix:
  • localhost/no tunnel -> WindowsNative
  • localhost/tunnel -> MacOverSsh
  • .ts.net -> Tailscale
  • 100.64.0.0/10 -> Tailscale
  • 192.168/10/172.16/172.31 -> RemoteLan
  • .local -> RemoteLan
  • public host -> Remote
  • invalid/missing -> Unknown
• Tunnel info state mapping.
• Diagnostic sorting/dedupe with topology/tunnel warnings.
• Settings round-trip if new persisted fields are added.
• Existing capability and command-center tests stay green.

Safe live tests

No screen recording, camera capture, or microphone.

1. Mac gateway over SSH tunnel:
   • Enable tunnel.
   • Expect Command Center topology: Mac over SSH.
   • Expect tunnel state: Up.
   • Health/channel events continue.
2. Localhost without tunnel:
   • Expect Windows native until WSL detection exists.
   • If no gateway, show clear connection warning.
3. Tailscale URL:
   • Use a synthetic settings profile or non-invasive connection check.
   • Expect topology classification only.
4. Remote LAN URL:
   • Expect Remote LAN classification.
5. Tunnel failure:
   • Stop only the known SSH process if started by the app.
   • Expect tunnel warning/restart state.
6. Allowlist regression:
   • Safe repair remains copyable.
   • Dangerous camera/screen commands remain informational.

Required validation

After code changes:

.\build.ps1
dotnet test .\tests\OpenClaw.Shared.Tests\OpenClaw.Shared.Tests.csproj --no-restore
dotnet test .\tests\OpenClaw.Tray.Tests\OpenClaw.Tray.Tests.csproj --no-restore

10. Open questions

1. Should DeclaredGatewayKind be a persisted user hint, or should detection remain purely derived?
2. Should Mac-over-SSH be named SshTunnel until presence confirms a Mac platform?
3. Should browser.proxy live in the tray, or should Command Center guide users to install/enable the browser plugin host?
4. Do we want a future "managed local gateway" mode, or only "detected local gateway"?
5. How much Tailscale integration should Windows own vs merely detect?
6. Should WSL detection use process/port probing, wsl.exe, or gateway presence fields once available?
7. Should support bundles include topology/tunnel diagnostics by default, and how should they redact host/user/IP? Implemented for Command Center copy support context with redacted gateway URL, topology detail, tunnel endpoints/errors, and port details.

11. Immediate recommendation

Implement Phase 1 now:

• Add topology/tunnel models and classifier.
• Surface them in Command Center.
• Add topology/tunnel warnings.
• Keep everything read-only and diagnostic.

This is the cleanest bridge between today's working Command Center and the Mac-style Mission Control product vision. It does not require a native Windows gateway, protocol changes, or privacy-sensitive live tests.