docs: propose OpenClaw-owned Rust node runtime - #54
Draft
giodl73-repo wants to merge 27 commits into
Draft
Conversation
clawsweeper
Bot
added
rating: 🦐 gold shrimp
|
Codex review: needs real behavior proof before merge. Reviewed August 12, 2026, 3:37 PM ET / 19:37 UTC. ClawSweeper reviewWhat this changesThis PR adds RFC 0028 and supporting specifications for an OpenClaw-owned Rust Gateway client, headless node runtime, and authenticated sidecar-hosting boundary. Merge readinessKeep open as a draft RFC: it requests a maintainer product decision about core ownership of a new Rust runtime, and current RFC policy requires acceptance plus an implementation issue before merge. Priority: P3 Review scores
Verification
How this fits togetherThe proposed runtime sits between product-owned native shells and the OpenClaw Gateway. Product adapters host native capabilities while the Gateway remains the authority for controller access and node lifecycle. flowchart LR
Shell[Product shell] --> Adapter[Product adapter]
Adapter --> Runtime[Rust node runtime]
Runtime --> Gateway[OpenClaw Gateway]
Controller[Authorized controllers] --> Gateway
Gateway --> Runtime
Runtime --> Native[Native capabilities]
Decision needed
Why: The branch documents a new cross-repository ownership and security boundary; source review can confirm RFC structure but cannot choose the product and maintenance commitment. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Obtain an explicit core-ownership decision; if sponsored, create the scoped implementation issue, change the RFC to accepted, and merge only that bounded design decision. Do we have a high-confidence way to reproduce the issue? Not applicable: this is a design proposal for new runtime ownership, not a report of broken current behavior. Is this the best way to solve the issue? Yes for design governance: an RFC with sidecar specifications fits repository policy, but it must remain draft until maintainers make the ownership decision and complete the accepted-RFC transition. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against af708f0ddb6f. LabelsLabel justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (46 earlier review cycles; latest 8 shown)
|
clawsweeper
Bot
added
feature: ✨ showcase
clawsweeper
Bot
removed
merge-risk: 🚨 compatibility
clawsweeper
Bot
added
status: ⏳ waiting on author
This was referenced Jul 30, 2026
clawsweeper
Bot
added
merge-risk: 🚨 compatibility
clawsweeper
Bot
added
the
merge-risk: 🚨 security-boundary
clawsweeper
Bot
added
rating: 🦐 gold shrimp
clawsweeper
Bot
added
rating: 🦐 gold shrimp
Contributor
Author
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
clawsweeper
Bot
added
rating: 🐚 platinum hermit
Contributor
Author
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What problem this solves
The new Copilot app system tray needs a native Rust node runtime, but placing
that runtime in Edge/Chromium would duplicate OpenClaw's protocol, lifecycle,
policy, and security behavior. OpenClaw also needs a clear boundary between its
reusable runtime and product-specific shells.
Why this change was made
This RFC proposes that OpenClaw own a reusable, headless Rust node runtime in
the OpenClaw monorepo, while Microsoft keeps product shells, native tools,
packaging, and deployment in Microsoft-owned repositories. The first proposed
host is the Copilot app system tray in Edge/Chromium.
Windows Companion and
openclaw-windows-nodeare a separate adopter. They canreuse the same crates to simplify their native stack and, independently, act as
authorized Gateway controllers for the tray node. Scout Cloud and other
authorized clients use the same Gateway-mediated path. Controller authority
stays in the Gateway; no controller connects directly to the local runtime.
The bounded decision is whether the two unpublished workspace crates should
incubate as an OpenClaw core surface beside the TypeScript reference. It does
not publish crates, make the proof host an official binary, promise platform
support, or accept broader node-mode parity. Those remain follow-on decisions.
During incubation, public Rust visibility is only an unstable workspace seam:
it carries no SemVer promise and may change atomically with reviewed in-tree
consumers. This RFC does not select a cross-repository distribution mechanism.
The RFC also makes the native trust boundary explicit. Product adapters are
trusted product code, not sandboxed plugins. The runtime authenticates,
authorizes, bounds, correlates, and cancels dispatch; the product retains OS
permissions, least privilege, containment, and any stronger isolation.
The RFC deliberately does not assign individual maintainers or ask for a
staffing decision. Implementation, review, and CODEOWNERS can follow normal
OpenClaw practice, and any later publication or official-binary proposal can
define the additional operational commitments it introduces.
Microsoft is the anchor adopter, not the exclusive audience. The runtime and
every accepted capability surface remain customer-neutral for native,
embedded, appliance, and headless adopters. Microsoft is willing to seed the
implementation and maintenance.
This is a convergence refactor, not the introduction of an unrelated Rust
stack. OpenClaw's Linux Tauri app already contains a production Rust Gateway
client for TLS trust, device authentication, reconnect, heartbeat, and request
handling. The foundation implementation extracts that app-local behavior into
the Tauri-free
openclaw-gateway-clientcrate and refactors the existing Tauriapp to consume it as the first adopter. The separate
openclaw-node-hostcratethen layers the reusable node role, lifecycle, and bounded runtime on that same
client. Tauri remains the application shell; native desktop and headless hosts
reuse the common Gateway substrate without taking a dependency on Tauri.
It is also consistent with OpenClaw's existing multi-language node model. The
generic TypeScript host, Apple Swift nodes, Android Kotlin node, official C#
Windows node, and official C ESP-IDF component all implement the same node role
while advertising different platform capabilities. Rust is another conforming
implementation, not a second protocol. The RFC proposes shared cross-language
fixtures so admission, identity, invocation, cancellation, lifecycle, and
errors converge even when tool catalogs legitimately differ.
The proposal is intentionally draft and leaves publication, production
sidecar adoption, broader command parity, and release support as explicit
follow-on decisions.
The hosting and management paths are deliberately separate:
sidecar adapter; and
Architecture sketch
Proposed implementation series
The RFC governs three OpenClaw implementation layers plus the Windows adopter
with distinct jobs:
extracts Tauri's Gateway transport into
openclaw-gateway-client, adds thebounded
openclaw-node-hostfoundation and headless binary, and makes theLinux Tauri app the first consumer of the shared client.
follows #116050 with the embeddable lifecycle: platform signing and typed
issued-device-token delivery, reconnect, duplex invocation, local
admission, connection-scoped manifests, and shared TypeScript/Rust
conformance fixtures. It must not land before #116050.
consolidates reviewed fork evidence #193-#195 into authenticated bounded
sidecar framing, the independently negotiated handshake, immutable
configuration, the ordinary-command runtime/product-adapter bridge, and a
real OS child-process authenticated IPC proof over loopback TCP.
It is logically stacked on #116450 and preserves the reviewed commits.
combines the replaceable runtime boundary, shared Windows capability
dispatcher, and independent C# reproduction of all three Rust corpora. It
routes ordinary native commands through that dispatcher while keeping C# as
the production default. The adapter is a non-selectable source proof;
production packaging/signing, Gateway lifecycle, supervision, rollout, and
rollback remain. Fork-only Rust #12
plus Windows #4
prove exact-hash launch with reparse-safe path locks through process
creation, private-pipe bootstrap, and handshake artifact binding without
enabling runtime selection.
The RFC now also specifies the next, not-yet-filed OpenClaw slice: a negotiated
sidecar Gateway connection-control exchange for per-attempt material,
supervisor-owned signing, durable issued-token acknowledgement, bounded
recovery, and authority retirement. The immutable capability configuration
stays secret-free. A later adopter slice can consume that contract over the
protected process channel and replace the current environment-based live proof.
Fork PRs #186-#192 remain evidence history. Fork PRs #193-#195 are closed as
superseded by upstream #116863; their reviewed commits remain in the cumulative
branch rather than becoming a permanent three-PR upstream stack.
User impact
No immediate user-facing behavior changes. The existing Linux Tauri app keeps
its product role while sharing its Rust Gateway implementation. If accepted,
other native products can reuse the same substrate and node runtime instead of
carrying a Node.js wrapper or a separate protocol implementation.
Implementation and evidence
with the Windows verified launcher
The RFC has also been reviewed through Gateway reliability, sidecar lifecycle,
enterprise security, and maintainer-correctness lenses. That review added
explicit fail-closed authority, audit, readiness, crash recovery, reconnect,
resource, and release gates. Current-head Rust evidence is green at #116050
1aaec0c5a56(56 tests) and #116450bfd5c4d14e2(73 tests plus strict staticgates, focused TypeScript conformance, and full protocol-generation checks).
The consolidated sidecar head
71c1c8cb23cin #116863 has 124 passing Rustworkspace tests plus strict Clippy and formatting. It proves the generic
protocol/handshake/configuration/ordinary-command bridge across a real child
process and transport, not production readiness. Fork evidence further proves anonymous-pipe IPC,
protected credential handoff, reparse-safe exact artifact identity through
launch, and authenticated self-identity. Platform signing and
packaging, duplex input/progress, product audit, crash supervision, resource
proof, rollout, and rollback remain explicit adopter gates.
The rebased Windows #1068 head
711fe095reproduces the protocol, handshake,and runtime corpora byte-for-byte; passes 63 focused sidecar/dispatcher, 3,701
Shared, and 22 focused Connection tests; and preserves the incumbent
pre-credential handshake authorization gate through the runtime seam. It closes the independent-consumer promotion gate for
the generic #116863 subset. Fork #4 then adds a non-selectable verified launcher;
the exact pinned aggregate passes 122 shared Rust and 64 focused Windows tests
plus all three fixture blobs. It does not close platform signing/package delivery,
Gateway/pairing/token,
system.*authorization, audit, crash/resource,selection, rollout, or rollback gates.
The sidecar connection-control contract includes a deterministic Ed25519
fixture and explicit races for timeout/cancellation, denial, authorization,
runtime closure, and supervisor retirement. Gateway, platform, and CISO role
review is recorded with the RFC. A final Codex review found the documents and
fixture internally consistent with no actionable correctness issue. This is a
reviewed implementation boundary, not a claim that either consumer exists yet.