fix(windows): make persistent agent sessions use the session host

[TashiikiD]

Summary

Windows already has a packaged session-host backend, but the main process could select an unrelated tmux.exe from PATH before reaching it. On a Windows machine with psmux/MSYS2/Cygwin available, that backend produced the failures seen in practice: agent launch text was corrupted, helper consoles appeared, and sessions could not be restored reliably.

This PR makes the Windows session host the authoritative local persistence backend and fixes the two launch integration issues that blocked usable agent sessions.

What changed

• Select the packaged session host on Windows. findTmux() now returns no local tmux binary on Windows. The existing session-host branch owns the PTY and provides attach, capture, send, and restart behavior. Unix systems retain their existing tmux discovery order.
• Preserve the Windows inherited PATH. Windows exposes the environment key as Path, while the Codex launcher path was built from env.PATH only. The Codex launcher now prepends its directory to env.PATH ?? env.Path ?? '', so codex, agy, opencode, and their subprocesses remain discoverable.
• Deliver a fresh persistent launch immediately. A newly created session-host terminal is already known to be a fresh shell. The renderer no longer waits for a pane-command probe before sending its queued initial command. Warm/manual recovery still verifies shell ownership before writing into a running session.
• Add regression coverage. The new source-contract test pins the Windows backend selection, PATH fallback, and fresh-launch guard. Existing command-delivery tests continue to cover echo verification, retries, and Windows Escape line clearing.

User-visible behavior

On Windows with persistence enabled:

• New Codex nodes launch codex --ask-for-approval on-request in the session host.
• New OpenCode nodes launch opencode in the session host.
• New Antigravity / Agy nodes launch agy in the session host.
• Closing and reopening NodeTerm reattaches to the same running CLI sessions, preserving the live process and terminal state.
• Sending follow-up messages continues to target the existing CLI process.
• NodeTerm does not select a PATH-installed psmux/MSYS2/Cygwin tmux executable, avoiding the extra cmd, PowerShell, node, git, and PTY helper windows that appeared with that backend.

Validation

Automated

• npm exec -- vitest run src/core/windows-session-persistence.test.ts src/renderer/terminal/launch-command.test.ts
  • 2 test files passed
  • 23 tests passed
• npm run typecheck
  • Node and web TypeScript checks passed
• git diff --check
  • Passed

Windows functional verification

Using the packaged Windows build with persistence enabled:

• Codex remained active across a full NodeTerm close/reopen cycle.
• OpenCode remained active across a full NodeTerm close/reopen cycle and reattached as opencode.exe.
• Agy/Gemini remained active across a full NodeTerm close/reopen cycle and reattached as agy.exe.
• The session-host PID remained unchanged across the restart, confirming the PTYs were owned by the detached host rather than the Electron process.
• A fresh Codex smoke node launched automatically and displayed the Codex UI.
• The host and PTY descendants had no visible Windows UI handles; the previous helper-console storm was gone.

Root cause

The persistence session-host implementation was present, but Windows discovery preferred any tmux.exe found on PATH. A Windows tmux-compatible executable is not interchangeable with the Unix tmux control contract used by NodeTerm. That mismatch caused incorrect input routing and visible child consoles. Separately, Windows environment casing dropped the inherited PATH, and the fresh session launch path unnecessarily queried pane ownership before delivering the initial command.

Scope

This PR changes only local Windows session selection and launch integration. Unix tmux behavior, SSH/remote sessions, and the existing session-host protocol are unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.