docs: supersede Hub Gateway Tools UI with package-owned Control UI

[MythiliMur]

Status: superseded implementation direction

This draft documents and contains the earlier Windows Hub client/UI slice for the package-side Gateway Tool Runtime Bridge.

The product direction has since moved the Gateway Tools management surface into the package-owned Gateway Control UI. Future UI work belongs in openclaw/openclaw-windows-packaging#92, alongside the authoritative broker, managed-profile lifecycle, and package-owned Control UI Adapter.

This PR remains a reference for the earlier bounded client DTOs and UI behavior, but it is not the landing target for the current feature.

Retained security intent

The earlier Hub client deliberately had no authority over:

• Gateway PATH, shims, ACLs, profiles, credentials, or lifecycle;
• arbitrary executable/process invocation;
• desktop credential-store, browser-profile, or token import;
• raw executable paths, identities, diagnostics, account data, or secrets.

Those boundaries remain required. The package-owned implementation will retain this bounded-status model while keeping privileged actions behind the packaging broker.

Validation

• git diff --check
• Focused view-model tests were added, but end-to-end verification was blocked by the environment's NuGet/TLS restore failure.

[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 real behavior proof before merge. Reviewed September 21, 2026, 10:00 PM ET / September 22, 2026, 02:00 UTC (Revision 3).

ClawSweeper review

What this changes

Adds a Windows Hub page, package activation and local broker client for registering desktop executables with the isolated Gateway, plus a design proposal and presentation tests.

Merge readiness

⛔ Blocked before merge - 22 items remain

Keep open: current main does not provide this capability. All seven previous findings remain, and the activation commit introduces three additional defects. The companion broker has progressed, but runtime readiness and the cross-identity security boundary remain unproven.

Priority: P2
Reviewed head: 55f9d914dc4ad871e0c6bc86a42e4651fa0cd059
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🧂 unranked krab (1/6)	The ownership split is useful, but unresolved compilation and runtime defects plus absent real behavior proof prevent readiness.
Proof confidence	🦪 silver shellfish (2/6)	Needs real behavior proof before merge: Authority-chain proof required: no current-head Windows evidence exercises the Hub activation, pipe exchange and registration flow against the real package. Show allowed registration and execution, rejection of a foreign caller or spoofed server, and effective removal of stale registration authority before execution. Include visible consent/status proof and redacted diagnostic output; screenshots alone cannot establish authorization. Replace the stale docs-only proof declaration with applicable pools, including windows-winui-interactive. Redact private data; updating the body should trigger re-review, or a maintainer can request @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Patch quality	🧂 unranked krab (1/6)	Security review found an item that needs attention.

Verification

Check	Result	Evidence
Real behavior	Needs proof	Needs real behavior proof before merge: Authority-chain proof required: no current-head Windows evidence exercises the Hub activation, pipe exchange and registration flow against the real package. Show allowed registration and execution, rejection of a foreign caller or spoofed server, and effective removal of stale registration authority before execution. Include visible consent/status proof and redacted diagnostic output; screenshots alone cannot establish authorization. Replace the stale docs-only proof declaration with applicable pools, including windows-winui-interactive. Redact private data; updating the body should trigger re-review, or a maintainer can request @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed	10 items	Pinned introduced scope: The pinned main-to-head delta adds 606 lines across 12 files: production +419, tests +76 and documentation +111. Review continuity: Read the complete previous review at #1460 (comment), recovering the omitted seventh finding about registration consent. Raw tree comparison shows only broker activation and the broker client changed since that review; inspecting the earlier client through GitHub confirmed its reported defects remain. Current-main necessity and release boundary: Current-main searches found no equivalent Gateway Tools registration or broker surface. The existing onboarding flow restarts an app-managed WSL Gateway to pick up installed tools, which does not provide this isolated-identity bridge. Inspection of the supplied latest-release tree likewise found no Gateway Tools implementation. Broader GitHub searches were blocked, so no exhaustive canonical-search claim is made.
Findings	10 actionable findings	[P1] Replace unsupported StringFormat bindings [P1] Constrain response types before passing null [P1] Include the activation dependency in the tray test build
Security	Needs attention	Package activation does not authenticate the pipe server: The client connects to a fixed machine-local name and sends selected executable paths without checking the server's identity. Activating the expected package does not establish that the connected endpoint belongs to it, especially if another principal created the pipe first. Registration lacks explicit execution consent: File selection and folder scanning dispatch operations that the companion broker persists as enabled registrations, without the proposal's explicit cross-identity approval step. Revocation is not established at the execution boundary: The Hub exposes Disable and Remove, but the companion registry changes stored state while existing shims can remain until runtime preparation. Prove or explicitly resolve when withdrawn registration authority stops reaching executable launch.

How this fits together

Gateway Tools connects desktop users to a package-owned broker that makes selected executables available to the isolated Gateway. The Hub requests operations and displays status; packaging owns registrations, runtime profiles and executable shims.

flowchart LR
  A[Desktop user] --> B[Gateway Tools page]
  B --> C[Package activation]
  B --> D[Local pipe client]
  C --> E[Packaging broker]
  D --> E
  E --> F[Registration and runtime permissions]
  F --> G[Isolated Gateway execution]
  E --> B

Loading

Decision needed

Question	Recommendation
Should this temporary Gateway Tools bridge remain a design proposal, or proceed as a coordinated Hub and packaging implementation?	Retain the design proposal: Defer executable integration until the broker contract and authority lifecycle are approved.

Why: No recorded maintainer decision sponsors the new cross-identity capability, and the companion implementation remains unmerged and incomplete.

Before merge

• Add real behavior proof - Needs real behavior proof before merge: Authority-chain proof required: no current-head Windows evidence exercises the Hub activation, pipe exchange and registration flow against the real package. Show allowed registration and execution, rejection of a foreign caller or spoofed server, and effective removal of stale registration authority before execution. Include visible consent/status proof and redacted diagnostic output; screenshots alone cannot establish authorization. Replace the stale docs-only proof declaration with applicable pools, including windows-winui-interactive. Redact private data; updating the body should trigger re-review, or a maintainer can request @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
• Replace unsupported StringFormat bindings (P1) - WinUI's Binding has no StringFormat property. These three status bindings and the Enabled binding prevent the page from compiling. Use formatted presentation properties, a converter or separate label/value elements. This previous finding remains unresolved.
• Constrain response types before passing null (P1) - T is unconstrained, so T? does not guarantee that a null literal is valid. The BrokerResponse<T>(null, ...) error paths fail compilation. Constrain the response types to reference types or use a valid generic default consistently. This previous finding remains unresolved.
• Include the activation dependency in the tray test build (P1) - The new call references GatewayToolsBrokerActivation, but Tray.Tests links this client source directly and does not include the new activation file or reference the WinUI project. The test project therefore fails to compile with an unresolved type. Add the dependency to its compile inputs or introduce a suitable injectable activation boundary.
• Activate the package through the COM activation manager (P1) - ActivateApplication is an IApplicationActivationManager COM method, not a shell32.dll export. This import raises EntryPointNotFoundException, which EnsureStarted silently catches, so a stopped broker is never launched. Use the supported activation interface and retain an actionable failure result.
• Derive the package family name with Windows identity APIs (P1) - Windows publisher IDs use Crockford Base32, whereas this code uses the RFC 4648 alphabet. It therefore constructs a different package family name for the declared publisher, so activation would still target a nonexistent application after fixing the COM call. Resolve the installed package identity or use PackageFamilyNameFromId instead of this custom encoder.
• Marshal observable state changes onto the UI thread (P1) - A real asynchronous broker call resumes after ConfigureAwait(false) on a worker thread, then mutates the bound collection or raises notifications whose handler directly updates ErrorInfoBar. This can throw a wrong-thread exception, including from the error path. Use IUiDispatcher for collection, selection, error and busy-state updates. The synchronous fake tests do not exercise this unresolved previous finding.
• Preserve broker errors when listing tools (P2) - An unavailable broker produces a null value and an error, but this expression discards the error and returns an empty list. Refresh then clears the displayed tools without reporting the failure. Preserve the distinction between a successful empty list and a failed request. This previous finding remains unresolved.
• Load tools through the navigation activation lifecycle (P2) - Nothing calls this Initialize method: HubWindow.InitializeCurrentPage has no Gateway Tools case, and the view model does not implement INavigationAware. Opening the page therefore leaves existing registrations invisible until manual refresh. Use the established activation lifecycle; adding only a switch case would run before DataContext assignment. This previous finding remains unresolved.
• Bound the entire broker request lifetime (P2) - The two-second timeout covers only connection establishment. A server that accepts the connection without completing a response line leaves ReadLineAsync waiting indefinitely because page handlers provide no cancellation token. IsBusy then suppresses every subsequent operation. Apply a deadline to the entire exchange and cancel work on navigation away. This previous finding remains unresolved.
• Confirm cross-identity registration before dispatch (P2) - Choosing a file immediately registers it without the proposal's explicit acknowledgement of Gateway execution access or confirmation of the alias. The companion registry defaults new registrations to enabled; its scan operation also registers discovered executables, so the Scan button needs an approval boundary too. Require confirmation before either path sends a registration request, and ensure cancellation sends nothing. The earlier consent finding remains unresolved.
• Resolve security concern: Package activation does not authenticate the pipe server - The client connects to a fixed machine-local name and sends selected executable paths without checking the server's identity. Activating the expected package does not establish that the connected endpoint belongs to it, especially if another principal created the pipe first.
• Resolve security concern: Registration lacks explicit execution consent - File selection and folder scanning dispatch operations that the companion broker persists as enabled registrations, without the proposal's explicit cross-identity approval step.
• Resolve security concern: Revocation is not established at the execution boundary - The Hub exposes Disable and Remove, but the companion registry changes stored state while existing shims can remain until runtime preparation. Prove or explicitly resolve when withdrawn registration authority stops reaching executable launch.
• Resolve merge risk (P1) - Starting the expected package does not authenticate the subsequently connected pipe server. A different local principal could pre-create the fixed pipe name; rejection before sending selected paths or accepting status remains unproven.
• Resolve merge risk (P1) - The coordinated implementation lacks final-effect evidence for foreign callers and disabled, removed or reassigned registrations; existing executable shims can outlive registry changes.
• Resolve merge risk (P1) - No compatible installed package demonstrates cold activation and complete Hub operations, including bounded recovery when the broker accepts a connection but stops responding.
• Complete next step (P2) - Resolve whether runtime integration is sponsored, then align the PR description and validation declarations with the selected scope and compatible packaging version.
• Improve patch quality - Resolve the ten findings and report the required Windows build, shared tests and tray tests.
• Improve patch quality - Record the coordinated product decision and supported packaging contract.
• Improve patch quality - Provide current-head UI and final-effect evidence for authorized use, foreign principals and revoked registrations.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Findings

• [P1] Replace unsupported StringFormat bindings — src/OpenClaw.Tray.WinUI/Pages/GatewayToolsPage.xaml:29-33
• [P1] Constrain response types before passing null — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:98-104
• [P1] Include the activation dependency in the tray test build — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:91
• [medium] Package activation does not authenticate the pipe server — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:92
• [medium] Registration lacks explicit execution consent — src/OpenClaw.Tray.WinUI/Pages/GatewayToolsPage.xaml.cs:45
• [medium] Revocation is not established at the execution boundary — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:72

Agent review details

Security

Needs attention: Registration consent, broker identity and persisted execution authority remain unresolved security boundaries.

Review metrics

Metric	Value	Why it matters
Introduced lines	production +419, tests +76, documentation +111; 0 removed	The growth implements a new UI and transport, making the documentation-only validation declaration obsolete.
Review continuity	7 prior findings remain; 3 new defects	The latest commit adds activation without resolving the previous build and runtime defects.

Merge-risk options

Maintainer options:

1. Defer runtime exposure (recommended)
   Keep the proposal while withholding executable controls until the packaging security contract and lifecycle are settled.
2. Complete the coordinated client
   Repair activation and UI behavior, authenticate the broker and demonstrate rejection and recovery at the real execution boundary.

Technical review

Best possible solution:

Keep the Hub a thin client behind an approved packaging contract, with explicit consent, verified broker identity, effective revocation and clear unavailable states.

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

Yes for the introduced defects: source and Windows API contracts establish build failures, invalid activation, missing navigation loading and unbounded waits. No Windows build or runtime reproduction was executed.

Is this the best way to solve the issue?

Unclear as a product direction. The thin-client ownership split is appropriate, but this implementation needs an approved broker contract and substantial correctness repairs before exposure.

Full review comments:

• [P1] Replace unsupported StringFormat bindings — src/OpenClaw.Tray.WinUI/Pages/GatewayToolsPage.xaml:29-33
  WinUI's Binding has no StringFormat property. These three status bindings and the Enabled binding prevent the page from compiling. Use formatted presentation properties, a converter or separate label/value elements. This previous finding remains unresolved.
  Confidence: 0.99
• [P1] Constrain response types before passing null — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:98-104
  T is unconstrained, so T? does not guarantee that a null literal is valid. The BrokerResponse<T>(null, ...) error paths fail compilation. Constrain the response types to reference types or use a valid generic default consistently. This previous finding remains unresolved.
  Confidence: 0.99
• [P1] Include the activation dependency in the tray test build — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:91
  The new call references GatewayToolsBrokerActivation, but Tray.Tests links this client source directly and does not include the new activation file or reference the WinUI project. The test project therefore fails to compile with an unresolved type. Add the dependency to its compile inputs or introduce a suitable injectable activation boundary.
  Confidence: 1
• [P1] Activate the package through the COM activation manager — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerActivation.cs:72-77
  ActivateApplication is an IApplicationActivationManager COM method, not a shell32.dll export. This import raises EntryPointNotFoundException, which EnsureStarted silently catches, so a stopped broker is never launched. Use the supported activation interface and retain an actionable failure result.
  Confidence: 0.99
• [P1] Derive the package family name with Windows identity APIs — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerActivation.cs:48-49
  Windows publisher IDs use Crockford Base32, whereas this code uses the RFC 4648 alphabet. It therefore constructs a different package family name for the declared publisher, so activation would still target a nonexistent application after fixing the COM call. Resolve the installed package identity or use PackageFamilyNameFromId instead of this custom encoder.
  Confidence: 0.99
• [P1] Marshal observable state changes onto the UI thread — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsPageViewModel.cs:30-34
  A real asynchronous broker call resumes after ConfigureAwait(false) on a worker thread, then mutates the bound collection or raises notifications whose handler directly updates ErrorInfoBar. This can throw a wrong-thread exception, including from the error path. Use IUiDispatcher for collection, selection, error and busy-state updates. The synchronous fake tests do not exercise this unresolved previous finding.
  Confidence: 0.99
• [P2] Preserve broker errors when listing tools — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:58-59
  An unavailable broker produces a null value and an error, but this expression discards the error and returns an empty list. Refresh then clears the displayed tools without reporting the failure. Preserve the distinction between a successful empty list and a failed request. This previous finding remains unresolved.
  Confidence: 1
• [P2] Load tools through the navigation activation lifecycle — src/OpenClaw.Tray.WinUI/Pages/GatewayToolsPage.xaml.cs:20-24
  Nothing calls this Initialize method: HubWindow.InitializeCurrentPage has no Gateway Tools case, and the view model does not implement INavigationAware. Opening the page therefore leaves existing registrations invisible until manual refresh. Use the established activation lifecycle; adding only a switch case would run before DataContext assignment. This previous finding remains unresolved.
  Confidence: 0.99
• [P2] Bound the entire broker request lifetime — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:93-97
  The two-second timeout covers only connection establishment. A server that accepts the connection without completing a response line leaves ReadLineAsync waiting indefinitely because page handlers provide no cancellation token. IsBusy then suppresses every subsequent operation. Apply a deadline to the entire exchange and cancel work on navigation away. This previous finding remains unresolved.
  Confidence: 0.99
• [P2] Confirm cross-identity registration before dispatch — src/OpenClaw.Tray.WinUI/Pages/GatewayToolsPage.xaml.cs:43-48
  Choosing a file immediately registers it without the proposal's explicit acknowledgement of Gateway execution access or confirmation of the alias. The companion registry defaults new registrations to enabled; its scan operation also registers discovered executables, so the Scan button needs an approval boundary too. Require confirmation before either path sends a registration request, and ensure cancellation sends nothing. The earlier consent finding remains unresolved.
  Confidence: 0.98

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 3e740827aeb1.

Labels

Label justifications:

• P2: This is an optional new desktop capability, with no demonstrated urgent regression in shipped behavior.
• merge-risk: 🚨 security-boundary: Executable registration crosses into an isolated identity without established server authentication and revocation guarantees.
• merge-risk: 🚨 availability: The introduced activation path cannot start the broker, while off-thread UI changes and unbounded responses can fail or stall the page.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Authority-chain proof required: no current-head Windows evidence exercises the Hub activation, pipe exchange and registration flow against the real package. Show allowed registration and execution, rejection of a foreign caller or spoofed server, and effective removal of stale registration authority before execution. Include visible consent/status proof and redacted diagnostic output; screenshots alone cannot establish authorization. Replace the stale docs-only proof declaration with applicable pools, including windows-winui-interactive. Redact private data; updating the body should trigger re-review, or a maintainer can request @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence

Security concerns:

• [medium] Package activation does not authenticate the pipe server — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:92
  The client connects to a fixed machine-local name and sends selected executable paths without checking the server's identity. Activating the expected package does not establish that the connected endpoint belongs to it, especially if another principal created the pipe first.
  Confidence: 0.98
• [medium] Registration lacks explicit execution consent — src/OpenClaw.Tray.WinUI/Pages/GatewayToolsPage.xaml.cs:45
  File selection and folder scanning dispatch operations that the companion broker persists as enabled registrations, without the proposal's explicit cross-identity approval step.
  Confidence: 0.98
• [medium] Revocation is not established at the execution boundary — src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:72
  The Hub exposes Disable and Remove, but the companion registry changes stored state while existing shims can remain until runtime preparation. Prove or explicitly resolve when withdrawn registration authority stops reaching executable launch.
  Confidence: 0.96

What I checked:

• Pinned introduced scope: The pinned main-to-head delta adds 606 lines across 12 files: production +419, tests +76 and documentation +111. (55f9d914dc4a)
• Review continuity: Read the complete previous review at docs: supersede Hub Gateway Tools UI with package-owned Control UI #1460 (comment), recovering the omitted seventh finding about registration consent. Raw tree comparison shows only broker activation and the broker client changed since that review; inspecting the earlier client through GitHub confirmed its reported defects remain. (src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:87, 55f9d914dc4a)
• Current-main necessity and release boundary: Current-main searches found no equivalent Gateway Tools registration or broker surface. The existing onboarding flow restarts an app-managed WSL Gateway to pick up installed tools, which does not provide this isolated-identity bridge. Inspection of the supplied latest-release tree likewise found no Gateway Tools implementation. Broader GitHub searches were blocked, so no exhaustive canonical-search claim is made. (docs/ONBOARDING_WIZARD.md:61, 3e740827aeb1)
• Dependency contract signal: The proposal explicitly depends on the packaging broker, and the client activates its package and sends registration, profile and setup operations. This establishes an actual dependency on the packaging protocol and authority boundary. (src/OpenClaw.Tray.WinUI/Presentation/GatewayToolsBrokerClient.cs:91, 55f9d914dc4a)
• Companion broker now exists: The open, unmerged companion feat(windows): add Gateway Tool Runtime Bridge shared profiles openclaw-windows-packaging#92 (docs: propose isolated Gateway tool bridge) now contains a named-pipe server, current-user authorization and a Broker package entrypoint. The client's string-valued source payload matches this server. This supersedes the earlier assertion that no transport exists; interactive setup still explicitly returns unavailable. (src/OpenClaw.Launcher/Gateway/GatewayToolsBroker.cs, c2774a67e366)
• Persistent authority and final effects: Registration persists executable paths and defaults new registrations to enabled. PrepareRuntime writes executable shims; disabling or unregistering updates the registry without immediately removing existing shims. These concrete consumers make consent, ownership and revocation evidence material to the Hub's controls. (src/OpenClaw.Launcher/Gateway/GatewayToolRegistry.cs, c2774a67e366)

Likely related people:

• Barbara Kudiess: Raw commit 2de791e adds src/OpenClaw.Tray.WinUI/Presentation/IUiDispatcher.cs:14 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: 2de791ecf408; files: src/OpenClaw.Tray.WinUI/Presentation/IUiDispatcher.cs)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

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

History

Review history (2 earlier review cycles)

• reviewed 2026-09-22T00:40:47.777Z sha 0405756 :: blocked before merge. :: none
• reviewed 2026-09-22T00:49:46.195Z sha 728d75e :: needs real behavior proof before merge. :: [P1] Replace unsupported StringFormat bindings | [P1] Constrain response types before passing null | [P1] Marshal observable state changes onto the UI thread | [P2] Preserve broker errors when listing tools | [P2] Load tool status through the navigation activation lifecycle | [P2] Bound the entire broker request lifetime

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: docs: supersede Hub Gateway Tools UI with package-owned Control UI This is item 1/1 in the current shard. Shard 0/1.

This temporary status tracks the active review worker. The completed review will appear in the durable ClawSweeper review comment.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[MythiliMur]

Closing because Gateway Tools management now lands in the package-owned Gateway Control UI. The authoritative Runtime Bridge is tracked in openclaw/openclaw-windows-packaging#92; the dependent package UI follow-up is openclaw/openclaw-windows-packaging#94. This Hub draft remains reference material for earlier bounded client/UI concepts, but it is no longer the implementation target.