chore: experiment with trimmed winnode publishing

[shanselman]

What Problem This Solves

This draft explores whether the standalone winnode CLI can be safely tree-trimmed before we decide to distribute it independently. Today, winnode is not included in the GitHub release installer or portable ZIP, so this experiment does not reduce current OpenClaw Companion release assets.

Why This Change Was Made

The experiment enables conservative partial trimming for winnode while copying OpenClaw.Shared.dll unchanged. It removes the CLI's reflection-based JSON pretty-print call and adds an independent x64/ARM64 CI job that publishes the trimmed CLI, verifies the Shared assembly remains byte-identical, and smoke-runs the executable.

The WinNode CI job is separate from Tray artifact publishing and is not a dependency of the release job. This PR intentionally does not trim or otherwise alter the Tray application.

User Impact

No current user-visible impact. This is an experiment for a possible future standalone winnode distribution.

Measured standalone x64 output:

Variant	Folder	ZIP
Self-contained, untrimmed	115.73 MiB	50.87 MiB
Self-contained, partial trim	60.24 MiB	25.56 MiB
Savings	55.49 MiB (47.9%)	25.31 MiB (49.8%)

Latest GitHub release v0.6.12 remains unchanged: x64 installer 114.12 MiB, ARM64 installer 99.90 MiB, x64 ZIP 141.64 MiB, ARM64 ZIP 133.04 MiB.

Evidence

• x64 trimmed publish: 60.24 MiB, 112 files, winnode.exe --help exited 0.
• ARM64 trimmed publish: 61.71 MiB, 112 files, winnode.exe --help exited 0 on an ARM64 host.
• OpenClaw.Shared.dll SHA-256 matched its pre-link build output immediately after both publish sequences.
• Publish completed with trim diagnostics treated as errors; no trim warnings were suppressed.
• Final rubber-duck review found no blocking or non-blocking issues after the WinNode CI gate was separated from Tray publishing.

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

Validation

• ./build.ps1 — passed; Shared, CLI, WinNode CLI, SetupEngine, and WinUI built successfully for win-arm64.
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore — 2,863 passed, 31 skipped, 0 failed.
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore — 1,717 passed, 0 failed.
• dotnet test ./tests/OpenClaw.WinNode.Cli.Tests/OpenClaw.WinNode.Cli.Tests.csproj --no-restore — 127 passed, 0 failed.
• dotnet publish ./src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj -c Release -r win-x64 --self-contained true — passed; Shared hash matched; --help passed.
• dotnet publish ./src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj -c Release -r win-arm64 --self-contained true — passed; Shared hash matched; --help passed.

Real Behavior Proof

• Environment tested: Windows 11 ARM64, .NET SDK 10.0.302; x64 publish exercised under Windows emulation and ARM64 publish exercised natively.
• PR head or commit tested: af85963f
• Exact steps or command run: publish each RID self-contained, compare SHA-256 of built and published OpenClaw.Shared.dll, then run the published winnode.exe --help.
• Evidence after fix: x64 60.24 MiB; ARM64 61.71 MiB; hash comparisons true; both executables exited 0.
• Observed result: conservative trimming removes about 48% of the standalone folder while preserving Shared byte-for-byte.
• Screenshot or artifact links verified? N/A
• Not verified or blocked: no live isolated-Tray MCP roundtrip was available locally. Before promotion from experiment, test the published binary on a clean second machine with no .NET SDK/runtime, run winnode --list-tools, and invoke a safe command such as system.which against an isolated Tray profile.

Security Impact

• New permissions or capabilities? No
• Secrets or tokens handling changed? No
• 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: N/A

Compatibility and Migration

• Backward compatible? Expected yes; still experimental pending clean-machine proof.
• Config or environment changes? No
• Migration needed? No
• If yes, list the exact upgrade steps: N/A

Experiment Risks

• The preservation hook attaches to the SDK-private _ComputeManagedAssemblyToLink target; a future SDK update could change that ordering. CI therefore verifies OpenClaw.Shared.dll byte-for-byte on both RIDs.
• Existing unit tests execute the normal test assembly, not every path through the published executable.
• Future winnode code that calls additional Shared functionality may require new published-binary tests.
• The CLI still carries speech/ONNX/native assets inherited from OpenClaw.Shared; trimming does not solve that dependency-boundary problem.
• The structured autoreview helper could not run because its secret scanner treated the existing OPENCLAW_MCP_TOKEN identifier in Program.cs as secret-like content. No secrets were added or changed.

Second-Machine Test Plan

1. Download or build the x64/ARM64 publish-winnode output on a clean Windows machine without the .NET runtime installed.
2. Run winnode.exe --help.
3. Launch the Tray with isolated data and enable Local MCP Server.
4. Set OPENCLAW_TRAY_DATA_DIR to that isolated profile.
5. Run winnode.exe --list-tools.
6. Run winnode.exe --command system.which --params '{"bins":["git","node","powershell"]}'.
7. Confirm output and exit codes match an untrimmed publish.

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.

[clawsweeper]

Codex review: found issues before merge. Reviewed August 23, 2026, 8:19 AM ET / 12:19 UTC.

ClawSweeper review

What this changes

This draft turns on partial trimming for standalone winnode publishes, preserves the Shared assembly unchanged, and adds x64/ARM64 CI publish checks.

Merge readiness

⚠️ Ready for maintainer review - 5 items remain

Keep open for explicit maintainer direction and two remaining review fixes: the trimmed published executable still is not exercised against Local MCP, and its new CI job uses an older setup action than current main.

Priority: P3
Reviewed head: af85963fe755bc085d1e4acceba8ed98a8234de7
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The patch has a bounded, documented experiment and passing CI, but its primary published-CLI behavior remains untested and the new job is behind the current action baseline.
Proof confidence	🌊 off-meta tidepool	Not applicable: The collaborator proof gate does not apply, but repository policy still requires published winnode Local MCP discovery and invocation evidence before this node/MCP change can merge.
Patch quality	🦐 gold shrimp (3/6)	2 actionable review findings remain.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: The collaborator proof gate does not apply, but repository policy still requires published winnode Local MCP discovery and invocation evidence before this node/MCP change can merge.
Evidence reviewed	5 items	Current main does not contain the experiment: The current-main WinNode project has no PublishTrimmed, TrimMode, or preservation target, so the central publishing change is not already implemented. Published smoke does not reach MCP: The added CI job invokes only winnode.exe --help; help returns before endpoint resolution, HTTP transport, tool discovery, or command invocation. Repository policy requires the missing proof: Applicable repository policy requires winnode --list-tools plus an invocation, or equivalent raw MCP tools/list and tools/call proof, for node/MCP changes.
Findings	2 actionable findings	[P2] Exercise Local MCP from the published executable [P3] Use the workflow’s current setup-dotnet major
Security	None	None.

Live Verification

Command: dotnet publish src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj -c Release -r win-x64 --self-contained --no-restore -o publish-winnode

Result: FAIL (failed) — execution before step 1 run: sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

sh -lc pnpm install --ignore-scripts --frozen-lockfile failed: ! Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-11.22.0.tgz

Assertions:

• FAIL expect_output: winnode - invoke OpenClaw node commands on the local Windows tray over MCP

How this fits together

winnode is the standalone terminal client for the tray app’s local MCP server. The publish pipeline produces a self-contained executable that must still discover and invoke the tray’s Windows-node tools after trimming.

flowchart LR
  A[WinNode source] --> B[Self-contained publish]
  B --> C[Partial trimming]
  C --> D[Published winnode executable]
  E[Tray Local MCP server] --> F[Tool discovery and invocation]
  D --> F
  F --> G[Windows node capability result]

Loading

Decision needed

Question	Recommendation
Should OpenClaw retain a permanently gated trimmed-winnode publishing experiment before standalone distribution is an approved product surface?	Keep it scoped as a draft: Require the published Local MCP proof and current CI baseline before deciding whether standalone distribution is worth supporting.

Why: The PR intentionally changes no shipped asset and frames trimming as a possible future standalone distribution, so the value of retaining ongoing CI cost and compatibility responsibility needs maintainer intent.

Before merge

• Exercise Local MCP from the published executable (P2) - --help exits before the CLI resolves its endpoint or makes a request, so both added jobs can pass while trimming breaks discovery, auth, HTTP dispatch, or result formatting. Run published --list-tools and a harmless command such as system.which against an isolated Local MCP tray; this is also required by the repository’s node/MCP proof policy.
• Use the workflow’s current setup-dotnet major (P3) - Current main uses actions/setup-dotnet@v6 in its test and packaging jobs, but this new job introduces @v5. Align it with the repository baseline so the new publish gate does not retain an older action runtime.
• Resolve merge risk (P1) - A trimmed binary can pass --help while failing its actual Local MCP discovery, authentication, HTTP, or result-formatting path.
• Resolve merge risk (P1) - The added CI job creates a second setup-action baseline and is behind current main’s actions/setup-dotnet@v6.

Findings

• [P2] Exercise Local MCP from the published executable — .github/workflows/ci.yml:574-576
• [P3] Use the workflow’s current setup-dotnet major — .github/workflows/ci.yml:542

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Patch size	4 files affected; production +74/-1, tests +50	Most production growth is a new cross-architecture CI job, so the executable’s end-to-end contract needs direct coverage.

Merge-risk options

Maintainer options:

1. Prove the published MCP path (recommended)
   Rebase onto current main, use the current setup-dotnet major, then have the CI job run published --list-tools and a harmless system.which call against an isolated Local MCP tray.
2. Defer the experiment
   Pause the trimming job until maintainers choose to support a standalone winnode package and its ongoing compatibility contract.

Technical review

Best possible solution:

Keep standalone trimming experimental until a rebased CI job proves the published executable can list tools and run a harmless Local MCP command against an isolated tray profile.

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

Yes, source inspection shows a deterministic gap: the added smoke command is --help, while the MCP request path begins only after argument processing and endpoint resolution.

Is this the best way to solve the issue?

No; reflection-safe JSON output and byte-identical Shared checks are useful, but they do not validate the published executable’s supported Local MCP operation.

Full review comments:

• [P2] Exercise Local MCP from the published executable — .github/workflows/ci.yml:574-576
--help exits before the CLI resolves its endpoint or makes a request, so both added jobs can pass while trimming breaks discovery, auth, HTTP dispatch, or result formatting. Run published --list-tools and a harmless command such as system.which against an isolated Local MCP tray; this is also required by the repository’s node/MCP proof policy.
  Confidence: 0.99
• [P3] Use the workflow’s current setup-dotnet major — .github/workflows/ci.yml:542
  Current main uses actions/setup-dotnet@v6 in its test and packaging jobs, but this new job introduces @v5. Align it with the repository baseline so the new publish gate does not retain an older action runtime.
  Confidence: 0.98

Overall correctness: patch is incorrect
Overall confidence: 0.98

AGENTS.md: found and applied where relevant.

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

Labels

Label changes:

• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• remove rating: 🦪 silver shellfish: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.

Label justifications:

• P3: This is an unshipped packaging experiment with no current user-facing release impact.
• merge-risk: 🚨 compatibility: Partial trimming changes the behavior of a future standalone executable, but its real MCP transport path is not yet proven after publish.
• merge-risk: 🚨 automation: The PR adds a two-RID CI job and uses an older setup-dotnet action major than current main.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🌊 off-meta tidepool and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: The collaborator proof gate does not apply, but repository policy still requires published winnode Local MCP discovery and invocation evidence before this node/MCP change can merge.

Evidence

What I checked:

• Current main does not contain the experiment: The current-main WinNode project has no PublishTrimmed, TrimMode, or preservation target, so the central publishing change is not already implemented. (src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj:1, ccd64bbb7d68)
• Published smoke does not reach MCP: The added CI job invokes only winnode.exe --help; help returns before endpoint resolution, HTTP transport, tool discovery, or command invocation. (.github/workflows/ci.yml:571, af85963fe755)
• Repository policy requires the missing proof: Applicable repository policy requires winnode --list-tools plus an invocation, or equivalent raw MCP tools/list and tools/call proof, for node/MCP changes. (AGENTS.md:40, af85963fe755)
• CI action baseline has advanced: Current main’s test job uses actions/setup-dotnet@v6, whereas the added job uses @v5. (.github/workflows/ci.yml:542, ccd64bbb7d68)
• Feature provenance: The original local-MCP WinNode CLI feature dates to Chris Anderson’s commit, with later live-tool work by Scott Hanselman. (src/OpenClaw.WinNode.Cli/Program.cs:42, 00dda4521698)

Likely related people:

• Scott Hanselman: Authored the later live-tool discovery work and has the largest visible history contribution across the WinNode CLI and related workflow paths. (role: recent area contributor; confidence: high; commits: 00dda4521698, af85963fe755; files: src/OpenClaw.WinNode.Cli/Program.cs, src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj, .github/workflows/ci.yml)
• Chris Anderson: Introduced the WinNode CLI for invoking local MCP node commands. (role: feature introducer; confidence: high; commits: 3b8793db3702; files: src/OpenClaw.WinNode.Cli/Program.cs, src/OpenClaw.WinNode.Cli/OpenClaw.WinNode.Cli.csproj)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Run the published executable against an isolated Local MCP tray with --list-tools and a safe system.which call.
• Rebase the workflow portion onto current main and use actions/setup-dotnet@v6.

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 (22 earlier review cycles; latest 8 shown)

• reviewed 2026-08-02T23:03:33.269Z sha af85963 :: needs changes before merge. :: [P2] Exercise Local MCP from the published executable | [P3] Match the repository's setup-dotnet major
• reviewed 2026-08-03T08:00:58.921Z sha af85963 :: found issues before merge. :: [P2] Exercise Local MCP from the published executable | [P3] Use the repository's current setup-dotnet major
• reviewed 2026-08-03T12:51:54.046Z sha af85963 :: found issues before merge. :: [P2] Exercise the published Local MCP transport path | [P3] Use the workflow's current setup-dotnet major
• reviewed 2026-08-03T14:56:59.193Z sha af85963 :: found issues before merge. :: [P2] Exercise the published Local MCP transport path | [P3] Use the repository's current setup-dotnet major
• reviewed 2026-08-03T20:16:18.559Z sha af85963 :: found issues before merge. :: [P2] Exercise the published Local MCP transport | [P3] Use the repository's current setup-dotnet major
• reviewed 2026-08-04T22:05:44.661Z sha af85963 :: found issues before merge. :: [P2] Exercise the published Local MCP transport | [P3] Use the repository's current setup-dotnet major
• reviewed 2026-08-09T01:04:39.281Z sha af85963 :: found issues before merge. :: [P2] Exercise Local MCP from the published executable | [P3] Use the workflow's current setup-dotnet major
• reviewed 2026-08-09T03:16:00.170Z sha af85963 :: found issues before merge. :: [P2] Exercise Local MCP from the published executable | [P3] Match the workflow's current setup-dotnet major

[github-actions]

This pull request has been automatically marked as stale due to inactivity.
Please update it or it will be closed.