feat(windows): add native Windows support

[keinstn]

Related to #51

Summary

Adds native Windows support to hcom and includes Windows release packaging: an x86_64 MSVC standalone archive, a PowerShell installer, and a win_amd64 Python wheel.

The implementation replaces POSIX-only assumptions with a platform abstraction layer and a Windows ConPTY backend while sharing path resolution, delivery state, terminal presets, and screen tracking across platforms.

What changed

• src/sys/: platform abstraction for process kill/signals, file permissions, sockets, stdin liveness. Windows process-tree kill re-scans for stragglers spawned mid-kill.
• src/pty/win.rs: ConPTY-backed PTY proxy for I/O, resize, titles, approval/delivery scraping, sharing cross-platform behavior through src/pty/shared.rs.
• Process launch: PowerShell runner scripts; .cmd/.bat npm shims through cmd.exe; graceful terminate and process-tree escalation; bounded child waits.
• Cross-platform paths/hooks: shared runtime path helpers, PowerShell permission support, and terminal presets represented as executable plus argv.
• CI: native Windows fmt, clippy, unit, release-build, package-smoke, and real-tool coverage.
• Release: x86_64-pc-windows-msvc cargo-dist artifact, PowerShell installer, and Windows maturin wheel.

Known limitations / deferred

• Antigravity hooks remain POSIX-only because its Windows execution mechanism is unconfirmed.
• DB archival can fail while another hcom process holds the file open on Windows.
• Secret files do not yet use Windows owner-only ACLs.
• hcom term hook-orphan detection and bash workflow scripts (confess, debate, fatcow) remain limited on Windows.
• Windows ARM64 packaging is not included; this release targets Windows x86_64.

Testing

• Unit, formatting, clippy, and TypeScript typecheck gates
• Native Windows build and compiled-binary smoke test
• Real Codex, Claude, and relay lifecycle matrices on Linux and Windows
• Manual end-to-end testing on Windows 11
• Release planning includes the Windows archive, PowerShell installer, and wheel

[aannoo]

Nice! Here is AI review, some may not be relevant/correct, you decide:

P1

Background processes are not detached on Windows

src/sys/process.rs (detach_session)

detach_session() sets only CREATE_NEW_PROCESS_GROUP. That makes the child
signallable as a group but leaves it sharing the parent's console, so the
background powershell spawn in terminal.rs (launch_terminal) dies when the
terminal closes. Headless agents and the relay worker are affected. The earlier
Python implementation (commit 50c9bfd) used CREATE_NO_WINDOW plus a hidden
startup config. Windows needs a real detached/no-window launch here, reconciled
with the Ctrl+Break shutdown path that only reaches processes on the caller's
console.

npm tool shims can't be launched through ConPTY

src/main.rs (pty dispatch), src/pty/win.rs (Proxy::spawn), src/terminal.rs (which_candidates)

which_bin() resolves extensionless names through PATHEXT, so a normal npm
install yields gemini.cmd or codex.cmd. That path goes straight to
portable-pty as the executable, which passes it to CreateProcessW as the
application name. Windows won't run .cmd/.bat files that way — they need
cmd.exe /c. Common npm-installed agents fail before the PTY starts even though
hcom found the tool.

Generated PowerShell files are not safe for Unicode input

src/launcher.rs (create_runner_script_windows, sidecar write), src/terminal.rs (create_powershell_script)

The .ps1 launchers and env sidecars are written as BOM-less UTF-8 (fs::write,
writeln!) and run through powershell — Windows PowerShell 5.1. Without a BOM,
5.1 reads them in the legacy ANSI codepage, so non-ASCII usernames, paths,
prompts, env values, or binary paths corrupt. Write a UTF-8 BOM (or target
pwsh).

Windows does not record user keyboard activity

src/pty/win.rs (stdin thread)

The stdin thread forwards bytes to ConPTY but never updates
ScreenState.last_user_input; the Unix path does on every keystroke
(pty/mod.rs). After the initial cooldown, the delivery gate
(delivery.rs) can treat a typing user as idle. Worst for tools like Gemini
where activity detection is the main gate and prompt-empty detection is off.

Gemini, Antigravity, and Claude hooks are POSIX-only

src/hooks/gemini.rs, src/hooks/antigravity.rs, src/hooks/claude.rs

All three emit sh -c, command -v, exec, POSIX env assignment, and
redirection; Antigravity also uses printf and base64 -d; Claude's command
sets no hook shell. On Windows these tools run hook commands through PowerShell
(Claude prefers Git Bash when present), and stock Windows isn't guaranteed to
have sh. The hooks fail, which disables registration, status updates,
bootstrap, and polling. Use each tool's cross-platform exec form or generate
PowerShell.

OpenCode and Kilo config/database paths are Unix-derived

src/hooks/opencode.rs (xdg_config_home, plugin_dir_for_app, get_family_db_path), src/integration_spec.rs

current_home_dir() falls back to dirs::home_dir(), but xdg_config_home()
reads only XDG_CONFIG_HOME/HOME. With both unset (common on Windows) it
builds /.config, so hcom can write hcom.ts under C:\.config\opencode\plugins
while OpenCode reads the real config dir — hook verification then passes against
a file the tool never loads. get_family_db_path() falls back to
$HOME/.local/share/... instead of the Windows data dir, so the transcript DB
can go unrecorded. Kilo is treated as an old OpenCode layout
(KILO_CONFIG_DIR, .kilo/plugins, ~/.local/share/kilo/kilo.db); current Kilo
puts config at %USERPROFILE%\.config\kilo\kilo.jsonc and the DB under
%LOCALAPPDATA%\kilo\kilo.db.

Database archival fails while another process holds the DB open

src/db/mod.rs (ensure_schema, archive_db_at)

Before archiving an incompatible DB, ensure_schema() swaps only its own
connection to in-memory. Other agents, relay workers, and hooks keep the file
open. archive_db_at() then calls remove_file() on the live path. SQLite on
Windows opens without FILE_SHARE_DELETE, so the delete fails while any handle
is open. A schema mismatch mid-session breaks at the archive step.

Native Windows is absent from every release channel

dist-workspace.toml, .github/workflows/build-wheels.yml, publish-pypi.yml, pyproject.toml, README.md

The cargo-dist target list and the wheel matrix have no Windows target; the
installer covers macOS, Linux, Android, and WSL; the PyPI classifiers advertise
macOS and POSIX only. pip install hcom and uv tool install hcom have no
Windows wheel. The new CI job proves the source compiles but ships nothing a
Windows user can install. Shipping the feature needs a Windows artifact and an
install-and-run smoke test against it.

P2

Approval detection is missing from the Windows delivery state

src/pty/win.rs (update_screen_state)

The Windows path defers approval scraping and never sets state.approval,
disabling the approval status and delivery gate for Codex, Cursor, and
Antigravity.

A terminated process can be reported as alive

src/sys/process.rs (is_alive)

is_alive() treats any successful OpenProcess() as proof of life. A process
object stays valid after termination while another handle is open (hcom and the
job object both hold one), so a dead child reads as running — delaying cleanup
and leaving stale state. Query GetExitCodeProcess() and require STILL_ACTIVE.

Codex file-edit tracking is not started

src/pty/mod.rs (start_delivery_thread), src/pty/win.rs

The Unix path starts codex_file_edits::run_transcript_watcher() for Codex; the
Windows path has no watcher. It records apply_patch edits for collision
detection, so parallel Codex agents lose the file-collision signal on Windows.

Delivery starts before the tool is ready

src/pty/win.rs (Proxy::run), src/pty/mod.rs (Proxy::run)

Windows starts the delivery thread right after the IO threads. Unix gates
start_delivery_thread() on the ready pattern or the delivery-start timeout.
The in-loop ready gate still applies on Windows, so premature injection is
partly contained, but the notify/inject ports register early and the startup
delay is gone.

Delivery-init failures don't fail the launch

src/pty/win.rs (spawn_delivery_thread), src/pty/mod.rs (start_delivery_thread)

If the Windows delivery thread can't open the DB or create its notify server, it
logs and returns; the child keeps running and run() reports a normal launch.
Unix sends an init result back and errors out on failure or timeout. A Windows
agent can look launched while delivery and wake-up are permanently dead.

ConPTY is never resized after startup

src/pty/win.rs (Proxy::spawn, Proxy::run)

The size is captured once at spawn; MasterPty::resize() is never called.
Full-screen tools keep stale dimensions after the window changes, breaking
rendering, wrapping, and screen parsing.

Headless shutdown skips the graceful phase

src/hooks/common.rs (stop_instance_inner), src/sys/process.rs

The stop path calls terminate_group(), waits up to 2s, then kill_group().
On Windows both map to kill_tree_win(), so the first call already force-kills
the tree. There's no SIGTERM-equivalent grace window for shutdown hooks,
transcript flushing, or state cleanup before background agents are terminated.

Process-tree termination can miss descendants spawned after the snapshot

src/sys/process.rs (kill_tree_win)

The kill walks one ToolHelp snapshot, deepest-first, root last. A child the
root spawns after the snapshot but before the root dies isn't in the tree. The
KILL_ON_JOB_CLOSE job object backstops ConPTY children, so this mainly affects
the background PowerShell path, which has no job object.

hcom term always returns an empty screen

src/pty/win.rs (inject thread)

Every SCREEN query is answered with an empty string. Known missing feature,
not parity.

The mintty preset runs PowerShell source with bash

src/shared/terminal_presets.rs, src/terminal.rs (windows_shellify_preset)

Windows generates a .ps1, but windows_shellify_preset() leaves
mintty bash {script} unchanged, so bash is handed a PowerShell script.

Custom Windows terminal paths are parsed with POSIX rules

src/terminal.rs (shell_split)

shell_split() treats every backslash outside single quotes as an escape, so
C:\Tools\terminal.exe is mangled unless the user finds a quoting workaround.

Closing supported Windows panes still requires sh

src/terminal.rs (close_terminal_pane)

Close commands always run through sh -c, including presets marked
Windows-supported. Without a POSIX shell, wezterm cli kill-pane and similar
never run; the process dies but the pane stays open and pane_closed is false.

Workflow scripts require bash

src/commands/run.rs

Bundled workflows write .sh files run with bash, and non-Python user
workflows always go to bash. Stock Windows can't run hcom run confess,
debate, fatcow, or custom shell workflows.

The update subsystem requires a POSIX shell

src/update.rs, src/commands/update.rs

The background check runs a script with sh -c, applying an update runs
sh -c, and the default command pipes the Unix installer to sh. On stock
Windows, update checks fail silently and hcom update can't apply a release.

Login-shell env reconstruction is Unix-only

src/shell_env.rs

The resolver defaults to /bin/bash, runs -lic, captures via printf/env -0,
and rejects pwsh/powershell. On Windows it fails and falls back to parent
inheritance, so nested launches miss the clean login env. It fails open, so this
is a quality gap, not a hard break.

Hook orphan detection is disabled

src/sys/io.rs (stdin_appears_broken), src/hooks/common.rs (poll_loop)

stdin_appears_broken() always returns false on Windows. If the parent tool
exits while its instance row remains, the hook can't detect the orphan and keeps
polling and holding its notify endpoint until timeout.

Secret files are not owner-only on Windows

src/sys/fs.rs (create_private_new, set_private), src/launcher.rs, src/config.rs, src/shell_env.rs

create_private_new() and set_private() are no-ops on Windows. Env sidecars,
config.toml (which can hold relay_psk), and the serialized shell-env cache
rely on inherited ACLs. Profile-local files are private by default, so the real
exposure is a custom HCOM_DIR under a shared/permissive directory.

Transcript search uses a separate Unix-derived resolver

src/transcript/opencode.rs (get_family_db_path), src/commands/resume.rs (opencode_family_data_dir)

Transcript search derives OpenCode/Kilo paths from XDG_DATA_HOME/$HOME and
skips the dirs::data_dir() fallback that resume uses. On the same Windows
machine, resume can find a DB under %LOCALAPPDATA% while search reports none.

Dynamic titles and status icons are absent from the Windows proxy

src/pty/win.rs, src/pty/mod.rs, src/runtime_env.rs (set_terminal_title)

The Windows proxy passes current_name/current_status to the delivery loop
but never writes OSC title sequences when they change. The hook fallback writes
to /dev/tty, which does nothing on Windows. Renames and status changes don't
reach the title.

Gemini transcript discovery and version check assume a Unix layout

src/hooks/gemini.rs (derive_gemini_transcript_path, get_gemini_version)

Transcript discovery builds $HOME/.gemini/tmp with no dirs::home_dir()
fallback, returning None on Windows without HOME — losing resume metadata
and rebinding. The version check looks for package.json next to the resolved
binary, which on Windows is a .cmd shim, so detection fails; an undetectable
version is treated as supported, so an old Gemini can slip past the gate.

Claude's PowerShell tool is absent from the permission allowlist

src/hooks/claude.rs (managed permission patterns)

hcom installs rules only for Bash(hcom ...) and Bash(uvx hcom ...). Windows
Claude can run hcom commands through its PowerShell tool, which the Bash rule
doesn't match, stalling an unattended agent at an approval prompt.

The generated runner discards the agent's exit code

src/launcher.rs (create_runner_script_windows, runner invocation), src/terminal.rs

The runner ends at & hcom pty ... without saving $LASTEXITCODE or calling
exit. It's launched via powershell -File, which returns 0 unless the script
exits explicitly. A failing agent, a nonzero PTY status, or the intended 130
kill code all report success. Capture $LASTEXITCODE after hcom pty and exit
with it.

The Windows PTY drops early launch context and pre-bind diagnostics

src/pty/win.rs, src/pty/mod.rs, src/instance_binding.rs, src/delivery.rs

The Unix proxy stores an early launch_context (PID plus terminal metadata like
WEZTERM_PANE, TMUX_PANE, KITTY_WINDOW_ID, ZELLIJ_PANE_ID,
KITTY_LISTEN_ON) and, on a pre-bind exit, records the exit code, time since
spawn, visible tail, and an exited_before_bind reason. Windows stores only the
PID and, on exit, checks only whether the code is 130 before stopping delivery —
no finalizer. So hcom can't close an early-failing agent's pane (no pane id), and
failures from PowerShell parsing, Unicode paths, missing binaries, .cmd shims,
hooks, or a wrong cwd lose the output needed to diagnose them. This builder is
largely platform-independent and should be shared.

Windows CI verifies compilation, not lifecycle

.github/workflows/ci.yml (windows-build)

The job runs cargo build --locked and cargo test --locked --bins.
Integration and real-tool suites stay Linux-only. Nothing exercises the
PowerShell launchers, ConPTY input/injection, .cmd shims, cwd propagation,
background survival, archival with concurrent handles, hook polling, Unicode
paths, pane closing, or tree shutdown. Every runtime failure above passes this
job.

P3

Exit code 130 is treated as proof of hcom kill

src/pty/win.rs (Proxy::run)

run() sets EXIT_WAS_KILLED whenever the child exits 130, without checking
that hcom sent the request. Any unrelated 130 is logged as a kill. 130 is a Unix
convention rarely produced on Windows, so collisions are unlikely.

Claude print-mode args use bash quoting in PowerShell

src/launcher.rs (build_claude_command), src/terminal.rs

build_claude_command() serializes args with the POSIX shell_quote(), so
don't becomes bash's 'don'\''t' instead of PowerShell's 'don''t' when
embedded in the script. Only the explicit print path (-p/--print, background
NativePrint) is affected, and only for args containing quotes.

Windows PTY input uses competing blocking writers and constant polling

src/pty/win.rs (stdin thread, inject thread)

Both threads write to ConPTY through the same Mutex<Box<dyn Write>>, each
holding it across a blocking write_all()/flush, so one can stall the other;
write errors are dropped. The inject thread also wakes every 10ms regardless of
activity. A single channel-fed writer plus an event-driven inject wait would
serialize both and centralize error handling.

Design notes

Two structural points behind several findings above:

• The Windows PTY reimplements the proxy's lifecycle and delivery orchestration
  rather than just the platform transport. That duplication is why readiness
  sequencing, init acknowledgement, launch metadata, failure finalization,
  approval state, resize, titles, and the Codex watcher were kept on Unix and
  dropped on Windows. The shared layer should own launch state, delivery
  startup, screen-state updates, status/title, finalization, and shutdown; the
  backend should only spawn, read, write, resize, wait, and kill.
• Terminal presets are shell strings parsed with POSIX rules and text-rewritten
  to PowerShell on Windows, expected to stay valid across bash, PowerShell, and
  cmd.exe. That's the root of the mintty, backslash, and quoting bugs. Presets
  should be an executable plus an argument vector with explicit platform
  variants, substituted per argument and launched directly.

[keinstn]

Hi, @aannoo

Thank you for your feedback! I'll check them later!

[keinstn]

Progress on review feedback

Here's where things stand. 18 of 37 items are resolved; the remaining 19 are work in progress.

Summary

Priority	Resolved	Open	Total
P1	2	5	7
P2	13	12	25
P3	1	2	3
Design notes	2	0	2
Total	18	19	37

---

P1 — Resolved ✅

Issue	Commit
Database archival fails while another process holds the DB open	178ed19 fix(windows): unblock schema archive + gate Unix-only unit tests
Gemini/Antigravity/Claude hooks are POSIX-only (Claude only; Gemini/Antigravity remain open)	55756a5 fix(windows): make Claude hooks fire on Windows 3c22da6 fix(windows): Claude runs hooks via Git Bash

P1 — Open ❌ (work in progress)

Issue	Status
Background processes are not detached on Windows	CREATE_NEW_PROCESS_GROUP only; CREATE_NO_WINDOW not added (sys/process.rs:208)
npm tool shims can't be launched through ConPTY	which_bin resolves to .cmd, passed directly to CreateProcessW with no cmd.exe /c wrapper
Generated PowerShell files are not safe for Unicode input	Written via fs::write with no UTF-8 BOM (src/launcher.rs:872)
Gemini / Antigravity hooks are POSIX-only	sh -c, printf, base64 -d — no PowerShell equivalent yet
OpenCode and Kilo config/database paths are Unix-derived	xdg_config_home / get_family_db_path unchanged
Native Windows absent from every release channel	No Windows target in dist-workspace.toml / build-wheels.yml / pyproject.toml

---

P2 — Resolved ✅

Issue	Commit
Approval detection missing from Windows delivery state	0d499df, 07dd78b
Windows does not record user keyboard activity	0d499df — note_user_keystroke called from stdin thread, updates last_user_input
Codex file-edit tracking is not started	0d499df — shared::start_delivery_thread now spawns the transcript watcher
Delivery starts before the tool is ready	0d499df, c47ea0e, ad15222, b4e8911 — ready-or-timeout gate moved into the reader thread
Delivery-init failures don't fail the launch	0d499df, ad15222, c47ea0e, 0c9a731 — launch_failed atomic + retry on transient errors
ConPTY is never resized after startup	0d499df — spawn_resize_watcher polls at ~200 ms and calls MasterPty::resize
Headless shutdown skips the graceful phase	1b19239 — terminate() now sends CTRL_BREAK_EVENT instead of force-killing
Process-tree termination can miss late descendants	9bf4582 — CreateToolhelp32Snapshot retried once on failure; KILL_ON_JOB_CLOSE job object backstops ConPTY children
Dynamic titles and status icons absent from the Windows proxy	0d499df — reader thread writes OSC title escapes via build_title_escape
Windows PTY drops early launch context and pre-bind diagnostics	4a5a41f, 0d499df — last_tail capture + finalize_launch_failure_after_exit
Windows CI verifies compilation only	2e9da0d — unit tests now run on Windows, not just cargo build
mintty preset hands a .ps1 to bash	1207acb — mintty open argv is now mintty powershell -ExecutionPolicy Bypass -NoExit -File {script}
Closing supported Windows panes still requires sh	1207acb — close commands are now launched directly via Command::spawn; no sh -c

P2 — Open ❌ (work in progress)

Issue	Status
Terminated process can be reported as alive	is_alive checks OpenProcess only; GetExitCodeProcess + STILL_ACTIVE not added (sys/process.rs:13)
hcom term always returns an empty screen	Known missing feature
Custom Windows terminal paths parsed with POSIX rules	args_common::shell_split still used for the HCOM_TERMINAL env-var path (terminal.rs:1861); d680b7c adds a doc comment only
Workflow scripts require bash	src/commands/run.rs unchanged
Update subsystem requires a POSIX shell	src/update.rs unchanged
Login-shell env reconstruction is Unix-only	src/shell_env.rs unchanged
Hook orphan detection is disabled	stdin_appears_broken always returns false on Windows (sys/io.rs:10)
Secret files are not owner-only on Windows	create_private_new / set_private are no-ops on Windows (sys/fs.rs)
Transcript search uses a Unix-derived resolver	src/transcript/opencode.rs unchanged
Gemini transcript discovery / version check assume Unix layout	derive_gemini_transcript_path / get_gemini_version unchanged
Claude's PowerShell tool absent from permission allowlist	src/hooks/claude.rs unchanged
Generated runner discards the agent's exit code	No $LASTEXITCODE capture or exit after {run_line} in create_runner_script_windows (launcher.rs:868); create_powershell_script is fixed but the native PTY runner path is not

---

P3 — Resolved ✅

Issue	Commit
Exit code 130 treated as proof of hcom kill	b6cfc5f — EXIT_WAS_KILLED now only set when the kill was actually requested by hcom

P3 — Open ❌ (work in progress)

Issue	Status
Claude print-mode args use bash quoting in PowerShell	build_claude_command uses POSIX shell_quote (launcher.rs:670)
Windows PTY input uses competing blocking writers	stdin and inject threads share the same Mutex<Box<dyn Write>> across blocking writes

---

Design notes — Resolved ✅

Issue	Commit
Windows PTY reimplements lifecycle/delivery orchestration	0d499df — portable PTY orchestration extracted to pty/shared.rs; Windows proxy now shares delivery-thread startup, ready-gate, approval state, resize, titles, and finalization with Unix
Terminal presets are shell strings parsed with POSIX rules	1207acb — presets rewritten as executable + argument vector with per-platform variants (PlatformArgv { default, windows }); windows_shellify_preset, shell_split, and parse_terminal_command removed

---

The bulk of the P2 runtime gaps (ConPTY lifecycle, delivery orchestration, approval detection, keyboard activity, Codex watcher, resize, dynamic titles, early launch diagnostics) and both structural design-note items are addressed. The remaining open items — hooks (Gemini/Antigravity), the update/workflow/shell-env stack, the release pipeline, and the three P1 launch-path issues (process detach, .cmd shims, Unicode BOM) — are work in progress.

[keinstn]

Pushed the fixes for everything I committed to in my previous reply — merged into feat/windows-support at 31fc83e. All landed as three review-scoped merge commits so each is separately diffable: 6ec8f5d (PTY/delivery), 5f89e09 (terminal/config), 31fc83e (cleanups).

Landed

P0

• 1 — ConPTY ESC[6n no longer hangs headless/background launches: the reader answers the DSR itself when stdout isn't a real console.
• 22 — the cmd/start fallback no longer pre-quotes {script}; spaced paths work through Command's own quoting.
• 23 — a reader-thread startup failure now fails the launch loudly instead of running a session with no screen tracking or delivery.

Delivery/PTY correctness

• 4 — hcom term no longer returns a silent ""; the reader maintains a snapshot the inject thread serves, refreshed within ~120ms of an idle agent's last frame.
• 5 — the Codex transcript watcher now starts only after delivery-init succeeds, so a retried transient failure can't spawn a duplicate.
• 6 — the delivery-start timeout no longer drops the join handle; it's kept and joined at shutdown. Windows only — Unix (macOS/Linux) keeps today's behavior (a delivery-init timeout aborts the session) to keep this PR's diff scoped to Windows; happy to open that as a separate change if you'd like the same fix there.
• 8 — delivery-start is now driven by an independent coordinator thread on a timer, not gated on the reader's next read().
• 15 — OutputModeFilter parses each DEC private-mode parameter individually now, instead of dropping/leaking the whole sequence based on prefix order.
• 25 — background launches resolve bash the same way run-here does (PATH then /bin/bash fallback), instead of a bare Command::new("bash").

Lower priority

• 11 — the ambient-env sidecar strip folds case on Windows (matches the paired PowerShell Remove-Item Env:), keeping Unix exact-case.
• 17 — a preset unsupported on the host platform is now rejected at both config validate and launch, closing the HCOM_TERMINAL bypass. User-defined TOML presets (including ones that override a built-in's name) are exempt from this gate, at both sites.
• 19 — hcom status reports "Windows Terminal"/"cmd.exe" instead of "unknown" on native Windows, mirroring the launch planner.

Cleanup (your suggested fix, adopted as-is)

• 24 — shell_split takes is_windows: bool now, matching the config.rs open_argv(is_windows) pattern; both branches are exercised on every host.
• 26 — the duplicated TOML-escape expression is one helper (runtime_env::toml_escape_path) now.

Partial adoption (as described previously)

• 20 — logs SetConsoleCtrlHandler failure; no retry (explained why in the prior reply).
• 21 — bash -c/-lc {script} (and more generally any non-adjacent {script} after a bash-family interpreter — bash, bash.exe, /bin/bash, etc.) now fails fast with a clear error instead of silently launching a broken command. Only the adjacent bash {script} form is rewritten to PowerShell.
• 30 — fixed the misleading caller-side comment in hooks/common.rs; the poll loop logic is unchanged (it correctly waits out Windows' async TerminateProcess).

Decisions section — "Git Bash required, fail loudly"

• hcom run's bash-dependent paths (workflow scripts, the non-.py branch) now give a clear "Git Bash required — install it and ensure bash is on PATH" error on Windows instead of an opaque spawn failure.

One thing I added beyond the original list

hcom status preset-availability display (commands/status.rs) wasn't in your review and isn't touched by the diff otherwise, but fixing 17/19 made it start lying: it showed ✓ for a preset the new platform gate would actually reject, and (pre-existing, unrelated to platform) ✗ for a valid user-defined preset. Made it consistent with the same gate. Flagging since it's outside your original 27 items — let me know if you'd rather that were a separate change.

Bugs my own fixes introduced, caught in review before landing

Ran a review pass on the three branches before merging and found four real regressions in my own work, all fixed before this merge:

• The hcom term snapshot (4) was leading-edge-throttled only — an idle agent's final frame could be missing indefinitely. Added a trailing-edge debounce (reader split into a producer/consumer pair with a bounded recv_timeout).
• That producer/consumer split initially used an unbounded channel, silently dropping the backpressure the old single-thread reader gave the child under heavy output. Bounded it (sync_channel).
• The bash--c detector (21) had both false negatives (bash -x {script}, bash.exe -c {script}, /bin/bash -c {script} all bypassed it) and a coincidentally-correct-but-arbitrary contains('c') heuristic. Replaced with the actual rule: any non-adjacent {script} after a bash-family interpreter is unrunnable, full stop.
• The platform-preset gate (17) rejected a user's own override of a built-in preset name, contradicting get_merged_preset's existing contract that an override replaces the built-in on both platforms. Fixed as above.

Still held on your answers

Nothing has changed here since my last reply — still waiting on you for:

• 2 (TS plugins hardcoding hcom) — my read is still that this is a launcher-side PATH gap on Unix, not a plugin fix. Haven't touched it.
• 34 (Codex writable_roots override) — still proposing fail-fast/warn over silently mutating the user's override. Haven't touched it.
• 12 (hcom run hard-codes python3) — held per your instruction, no action taken.
• 13 (config --edit default vim) — held, out of this branch's diff, no action taken.
• 14 (transcript search needs rg/grep) — held, out of this branch's diff, no action taken.

Ready for another pass whenever you have time.

[aannoo]

Nice, made some fixes

[keinstn]

Thank you for the thorough review throughout this PR, and for taking it the rest of the way to merge — it made the Windows support much more solid than it would have been otherwise.

One nice touch: a couple of your follow-on commits resolved items I'd deliberately left as deferred follow-ups (the delivery-init retry behavior, and probing bash --version instead of trusting which_bin). Glad to see it land in v0.7.23.

Thanks again for the collaboration — happy to help with anything that comes up down the line.