Skip to content

fix(windows): exit native host on backend disconnect - #17

Merged
sheehanmunim merged 2 commits into
munimtechnologies:mainfrom
ElliotDrel:fix/windows-native-host-backend-eof
Oct 8, 2026
Merged

sheehanmunim merged 2 commits into
munimtechnologies:mainfrom
ElliotDrel:fix/windows-native-host-backend-eof

Conversation

@ElliotDrel

Copy link
Copy Markdown
Contributor

Summary

Fixes #16.

Terminate the Windows native-host relay when its server-to-Chrome reader finishes. Chrome keeps the host's stdin open while its native port exists; returning from the backend reader alone leaves the process blocked in the opposite direction. Chrome never sees native-port disconnect and the extension keeps a stale port.

This adds a Windows-only std::process::exit(0) at the end of that reader. It covers backend EOF/read failure and Chrome-output failure. Linux and macOS behavior, extension reconnect scheduling, MCP schemas, approval policy and dependencies remain unchanged.

Regression and CI

Add scripts/test-native-host-restart.py, a Python standard-library-only Windows harness using random isolated Win32 named pipes, explicit HANDLE signatures, bounded reads/writes and cleanup. No Chrome, registry or live backend is touched.

The four scenarios cover:

  • Bidirectional UTF-8 native framing, fragmented and consecutive frames.
  • Backend EOF while Chrome-side stdin remains open: relay must exit within three seconds.
  • Normal Chrome-side stdin EOF while the backend remains open.
  • Replacement relay and replacement backend reusing the same pipe after simulated restart.

The Windows CI job now builds the executable and runs the harness with Python 3.11.

Executed validation

Based on current main, deb4c7a:

  • cargo test --locked --manifest-path windows-linux/Cargo.toml: 93 passed on Windows.
  • cargo build --locked --manifest-path windows-linux/Cargo.toml: passes.
  • Harness with the fix: 4/4 pass.
  • Restore original run_native_host, rebuild, rerun: 2/4 pass, backend EOF and restart fail because the host stays alive after three seconds.
  • Restore fix, rebuild, rerun: 4/4 pass, backend EOF exits in 0.157 seconds in that run.
  • git diff --check: passes.

Earlier validation of the same five-line repair on release v0.6.0: Windows source tests 92/92; Linux source tests baseline and patched 94/94 each; initialization, all 32 MCP schemas and disconnected response comparison unchanged. Those release-base checks are distinct from the current-main Windows results above. Current-main cross-platform CI has not yet run at submission time.

A local native-host-only deployment restored live Chrome list/open/read/close after a one-time retirement of verified stale relays. Chrome automatically launched replacements. No live gateway restart or OS reboot was used as a test. The isolated regression verifies process/transport restart, not the Chrome reconnect scheduler itself.

Risk and scope

Process exit skips destructors and can interrupt an in-flight browser action when the backend disappears. That is preferable to retaining a dead native port. Completed outbound frames are flushed by the existing loop before EOF is observed. Exit is confined to the Windows native-host subprocess; it cannot terminate the MCP/backend process.

No changes to site approvals, desktop fallback, Chrome profiles, or the separate child-tab ownership defect (#14).

@sheehanmunim
sheehanmunim merged commit d524e90 into munimtechnologies:main Oct 8, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows native host stays alive on backend EOF and prevents Chrome reconnection

2 participants