Repository navigation
Add Named Pipe transport to nodespace CLI for Windows support #1452
Description
Problem
The nodespace CLI currently only supports Unix Domain Socket transport (#[cfg(unix)]). On Windows, run() returns an error stub. This blocks the agent/skill workflow on Windows — Claude Code, Gemini CLI, and Codex cannot interact with NodeSpace via the CLI on that platform.
The daemon (nodespaced) already has Named Pipe transport implemented (Windows Named Pipe via tokio::net::windows::named_pipe, added in #1440). The CLI needs the same.
Goal
nodespace CLI works on Windows by connecting to nodespaced over a Named Pipe instead of a Unix Domain Socket.
Implementation
- Add
#[cfg(windows)]transport inpackages/cli/src/lib.rsmirroring the daemon's Named Pipe setup - Named Pipe path:
\\.\pipe\nodespace(same pipe the daemon listens on) - Replace the
anyhow::bail!Windows stub inrun()with a real implementation - Update
connect(),connect_import(),connect_session(),connect_local_agent()to use Named Pipe channel on Windows resolve_socket_path()is Unix-only — add aresolve_pipe_name()for Windows
Unblocks
- Windows
.msiinstaller bundling the CLI (Unified installer: bundle GUI, CLI, and daemon into a single install #1448) - Agent/skill workflow on Windows (Claude Code, Gemini CLI, Codex via
nodespaceskill)
Activity
mstomar125 commentedon Aug 7, 2026
Board → Blocked (needs a Windows build environment). This is
#[cfg(windows)]code; the current remote is darwin, and the pre-push gate builds the macOSnodespacedand never compiles the Windows cfg block — so it can't be implemented or verified here. Pick up on a Windows toolchain. (Note: #1498 unblocks nodespace-sync#246.)mstomar125 commentedon Sep 14, 2026
Starting implementation. Baseline:
bun run testgreen (240 files, 4951 tests) on worktreeissue-1452-windows-pipe-cli@d47af353. I have real SSH access to a Windows 11 box this session for genuine build+run verification (not just cross-compilation check) — will report real terminal evidence in the PR.mstomar125 commentedon Sep 14, 2026
Resolved via PR #2610: #2610
Added a Windows Named Pipe client transport (
dial_channel()on#[cfg(windows)], plusresolve_pipe_name()) dialing the same\\.\pipe\nodespace-daemonpipe the daemon already serves (#1440), mirroring the desktop app's existing client-side pipe transport. Removed theanyhow::bail!Windows stub —run()/connect()/connect_import()/connect_session()/connect_local_agent()/connect_database()are now a single cross-platform implementation, not duplicated per platform.Real Windows verification (not simulated — genuine SSH access to a physical Windows 11 box this session):
Hit a real, pre-existing environment gap:
nodespace-cli/nodespace-daemoncan't currently be linked on that box becausenodespace-nlp-engine(a mandatory dependency ofnodespace-daemon) needslibclangforllama-cpp-sys-2's bindgen step, which isn't installed there, and installing LLVM was blocked by this session's safety classifier (unrelated to this fix — the GNU toolchain's own C compiler was present and used successfully once put on PATH).To verify the actual new transport code for real despite that, I built a standalone harness containing a byte-for-byte copy of the new client-side
dial_channel/resolve_pipe_nameand the daemon's own server-side Named Pipe plumbing (NamedPipeConn/ServerOptions), and ran a genuine client/server round trip over a real Windows Named Pipe on the box:Server side confirmed the same connection:
Full detail, including the exact libclang failure and the harness source, is in the PR description. MSVC target not evaluated (VS Build Tools not installed on the box, out of scope per this task's own guidance) — CI/release Windows builds should cover it;
tokio::net::windows::named_pipeis ABI-agnostic so nothing here is MSVC/GNU-specific.bun run test:allandquality:fixboth clean on the Mac worktree; Unix/macOS path unchanged and still passing (107 CLI unit tests).Restrict Windows Named Pipe to an owner-only DACL and fail loudly on …
Restrict Windows Named Pipe to an owner-only DACL and fail loudly on …