[jlongster]

Issue for this PR

Closes #

Type of change

• New feature

What does this PR do?

Adds pipe mode (create_pipe) to the process daemon on Windows. A pipe process
is a command with no terminal: no console is ever created (CREATE_NO_WINDOW),
stdin is NUL, stdout and stderr share one inheritable byte-mode named pipe
read with overlapped I/O, and the child is created inside a kill-on-close job
so TerminateJobObject reaches every descendant. Signals are hard kills on
Windows (there is no console to send Ctrl+Break to) and the exit reports the
signal the daemon sent (SIGTERM/SIGINT/SIGKILL) instead of a platform
exit code. If an outer job refuses the child, the command still runs and only
the main process is killed, with a warning. No feature flag and no protocol
change.

The implementation is split into platform-neutral pipe logic plus
service/pipe/unix.rs and service/pipe/windows.rs; Unix behaviour is
unchanged. Windows coverage lives in tests/pipe_windows.rs (ordered
stdout/stderr, exit code, exact environment, truncation, reparse point
rejection, output lines, wait/signal/terminate, jobs and grandchildren, the
1 s drain, no console window, and a shared output file), plus unit tests for
the command-line and environment encoders; SPEC.md describes Windows pipe
mode.

This is Phase 1 (daemon) of the Windows pipe-mode plan. Follow-ups: the
0.5.1 release and then the OpenCode-side gate removal.

How did you verify your code works?

Local: cargo fmt --check, cargo clippy --locked --all-targets --all-features -- -D warnings,
Windows-target clippy (--target x86_64-pc-windows-msvc), and
cargo test --locked --lib --test service --test runtime --test ownership --test pipe --test rows --test ghostty-effects
on Linux.

Windows: the check-process-daemon jobs run the full suite natively on
x64 and arm64. Run
42915684197:
Windows (x64) and
Windows (arm64)
pass, with all 14 pipe_windows tests and the new unit tests green on both,
alongside the Linux, macOS and Miri jobs.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

---

Added by the opencode bot (AI-generated).

Related: #57813, #57311

[opencodejr]

I couldn't run this here: there's no Rust toolchain in this environment, and the change only runs on Windows. I reviewed the diff by reading it and relied on the Windows x64/arm64 CI run linked in the description. The design looks sound: the job created with the process, the handle list limiting what the child inherits, cancel and exit taking priority over output in the reader, and the 1 s drain all hold up. The Unix code is only moved.

Public API: unchanged. create_pipe now works on Windows instead of failing; the protocol shape is the same.

Two things are worth fixing before OpenCode starts sending Windows requests (inline): program lookup ignores the request's PATH, which differs from Unix, and arguments passed to .bat/.cmd programs can be injected.

Related: #57813, #57311

[opencodejr]

With no application name, CreateProcessW looks up a bare program in the daemon's own directory, the daemon's current directory, the system directories and the daemon's PATH. It ignores both the PATH in request.env and request.cwd. On Unix, Command::new(program).env_clear().envs(env) uses the request's PATH, and so does Rust std on Windows. So the same request can find a different binary, or none, on each platform, and the daemon's current directory is searched too, a known place for a planted binary to be picked up. SPEC.md documents this, but since OpenCode builds one request for both platforms, could the program be resolved against the request's PATH (and PATHEXT), or a bare name be rejected, so behaviour matches Unix?

[opencodejr]

When program is a .bat/.cmd file, CreateProcessW runs it through cmd.exe, which splits the command line by its own rules, not MSVCRT's. With this quoting, an argument containing ", &, | or % can break out and run extra commands (the "BatBadBut" issue, CVE-2024-24576; Rust std now escapes or refuses these). Callers are told to wrap shell commands in cmd.exe /c themselves, but a request whose program is a batch file goes through this path silently. Could batch files be rejected, or their arguments escaped the way std does?

[opencodejr]

I couldn't run this here: there's no Rust toolchain in this environment and the change only runs on Windows, so I read the new commit. The reap after a failed connect now waits for the cancelled operation, so output_pipe can no longer return while Windows still uses the OVERLAPPED. The test changes (quoted script paths, a batch parent that waits for the grandchild to start writing) make the drain test check what it claims, and they stay within the existing time limits. The earlier points on program lookup and .bat/.cmd arguments are not addressed yet. Public API: unchanged.

[opencodejr]

I couldn't run this here (no Rust toolchain, Windows-only tests). The new commit only changes tests/pipe_windows.rs, and the earlier points on program lookup and .bat/.cmd arguments are still open. One thing is new: the reason the tests moved to batch files points at a problem in the daemon itself (inline). Public API: unchanged.

[opencodejr]

This works around a problem in the daemon, not just in the tests. SPEC.md tells callers to run shell commands as cmd.exe with ["/c", command]. cmd.exe doesn't treat \" as an escaped quote, so the \" escaping in command_line garbles any command containing a quoted path (cd "C:\Program Files" && ...), as this comment says. OpenCode will hit that once the gate is removed. Rust std offers raw_arg for exactly this case. Could cmd.exe /c (or the protocol) take the command line verbatim, so a shell command reaches cmd.exe unchanged? Then the tests could keep their inline commands.