docs: propose RFC 2562 self-hosted paired multi-host Driver

[skyzea1]

Summary

• Propose RFC 2562: self-hosted paired multi-host remote connection for physical PCs (comp1 → comp2/comp3)
• Keep one typed CuaDriver contract; multi-host is a connection backend, not a second tool schema
• Pairing + on-target consent, fail-closed auth, private-network defaults (avoid cua computer-server binds all interfaces and disables authentication by default in local mode (CONTAINER_NAME unset), exposing unauthenticated remote command execution, arbitrary file read/write, and PTY shell #1892-class open binds)
• Align with environment convergence (#2512 / PR #2513) and runtime/adapter model (RFC 2549)
• Improve on HTTP-only sketch #1858 by making generated Driver framing the source of truth

Review focus

• Whether PairedHost should share exact generated remote envelopes with Fleet ([RFC]: Converge Cua Driver across Sandbox, Lume, Fleet, and Cua-Bench #2512), differing only by credential issuer
• Pairing ceremony + scope model adequacy
• Bind/auth defaults and danger flags
• Phase A tool subset gate (screenshot/click/type first)
• Naming (paired-agent vs alternatives)
• Windows interactive session / macOS TCC / Linux session placement gates

Tracking

• Discussion: [RFC] Self-hosted multi-host paired remote Driver for physical PCs (comp1→comp2/comp3) #2562
• Consumer (non-Cua): [Feature]: Multi-host computer_use via paired Cua Driver hosts (comp1 → comp2/comp3) NousResearch/hermes-agent#71157

Validation

• Follows rfcs/0000-template.md structure and rfcs/README.md lifecycle (status: review)
• Filename rfcs/2562-*.md matches discussion issue number
• Links related RFCs/issues; no credentials or private data
• Maintainer review period per RFC process

Note on release metadata

Title uses docs: intentionally — RFC text only, no cua-driver code release.

[f-trycua]

I pushed a maintainer edit that preserves the original contributor commits and turns the security-sensitive parts of the proposal into reviewable decisions.

The revision now:

• states the exact dependency boundary with RFC 2549: this RFC adds a paired physical-host backend and does not redefine runtime/session authorization;
• reuses standard, bounded, unrestricted, and SessionManifest instead of creating a parallel remote-scope model;
• makes authorization a target-enforced intersection of runtime ceiling, pairing grant, immutable connection-bound session, policy, and protected consent;
• keeps unrestricted remote operation possible only after explicit target launch-time danger acknowledgement plus an explicit target-local pairing grant;
• specifies a standards-based v1 ceremony: a single-use ≥128-bit QR/copy-paste payload, TLS 1.3 mutual raw-public-key authentication, ALPN, and TLS exporter channel binding; a future short typed code must use SPAKE2+;
• makes pairing and host selection administrative operations, never model-facing MCP tools; each MCP server is pinned to one host;
• requires a persistent target-local indicator and Stop control while attached;
• defines revoke, reconnect, stale-handle, and unknown mutating-action behavior without claiming exactly-once execution after crashes;
• separates Cua responsibilities from harness responsibilities and explains how Hermes/Pi/custom SDK users, Claude Code/Codex MCP users, OpenClaw node fabrics, and Fleet-style custom carriers fit;
• adds protocol/platform spikes and substantially stronger cross-platform acceptance tests.

I intentionally left status: review. The remaining questions are product/API choices (multi-controller default, naming, indicator UX, SDK spelling, first stream carrier, and persistent-grant expiry), not missing security boundaries.