code-coordinator 0.5.571__tar.gz → 0.5.573__tar.gz

{code_coordinator-0.5.571 → code_coordinator-0.5.573}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.571
+Version: 0.5.573
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT

{code_coordinator-0.5.571 → code_coordinator-0.5.573}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.571
+Version: 0.5.573
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT

{code_coordinator-0.5.571 → code_coordinator-0.5.573}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.571",
+  "tag": "0.5.573",
   "distance": 0,
-  "node": "g0b8e275348da7bd146b160ece1e4c28c9c8274da",
+  "node": "g05352d1d1a6caa0eaee8083e67ae6f4aa685847e",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-10-03"

{code_coordinator-0.5.571 → code_coordinator-0.5.573}/coord/win_native_driver.py

@@ -51,6 +51,19 @@ operator's own work, not just this driver's child. See
 ``test_no_image_name_kill_path_exists_in_the_module`` — a source-level
 regression guard, not just a behavioral one.
 
+**UNC ``cwd`` (#3543).** A WSL-hosted agent's repo worktree translates
+(``coord.win_native_bridge.translate_to_windows_path``) to a UNC path
+(``\\wsl.localhost\\Ubuntu-24.04\\...``) — the normal case for dell64, this
+fleet's only WSL-hosted ``windows``-capability agent. ``cmd.exe`` (what
+``subprocess.Popen(..., shell=True)`` always launches on Windows)
+categorically refuses a UNC current directory at its own startup and
+silently falls back to ``%windir%`` instead, breaking every relative path
+in ``run_command``. :func:`_popen_command_and_cwd` folds cmd.exe's own
+``pushd`` UNC-to-drive-letter workaround into the launched command for a
+UNC ``cwd`` rather than ever handing cmd.exe one directly; see
+:class:`Win32Calls`'s :meth:`~Win32Calls.launch`/
+:meth:`~Win32Calls.launch_in_terminal`.
+
 **Spec steps** (:func:`parse_native_spec`, YAML — the ``win-native``
 sibling of ``tui-pty``'s smoke spec):
 
@@ -762,6 +775,114 @@ def _vkey_for(key: str) -> tuple[int, bool]:
     raise WinNativeSpecError(f"unrecognized key {key!r}")
 
 
+def _is_unc_path(path: str) -> bool:
+    """True for a UNC path (``\\\\server\\share\\...``) — the shape
+    :func:`coord.win_native_bridge.translate_to_windows_path` returns for a
+    WSL-hosted repo (``\\\\wsl.localhost\\<distro>\\...``, #3543)."""
+    return path.startswith("\\\\")
+
+
+def _popen_command_and_cwd(command: str, cwd: str) -> tuple[str, str | None]:
+    """Resolve the ``command``/``cwd`` pair to actually hand
+    ``subprocess.Popen(..., shell=True)`` (#3543).
+
+    ``shell=True`` on Windows always runs *command* via ``cmd.exe /c`` —
+    and cmd.exe's own startup categorically refuses a UNC current
+    directory: confirmed directly (``cmd.exe /c "cd \\\\wsl.localhost\\...
+    && dir"`` prints "CMD does not support UNC paths as current
+    directories.") and **silently** falls back to ``%windir%``
+    (``C:\\Windows\\System32``) instead of raising — this is cmd.exe's own
+    initialization check, not a ``CreateProcess``/``lpCurrentDirectory``
+    limitation (that accepts a UNC path fine, which is exactly why the
+    failure is silent: nothing downstream of ``Popen`` ever sees an error,
+    every relative path in *command* just silently resolves against the
+    wrong directory instead).
+
+    For a UNC *cwd* this folds cmd.exe's own standard UNC workaround —
+    ``pushd`` (maps an unused drive letter to the UNC path, cds into it) —
+    into *command* itself, and returns ``cwd=None`` so ``Popen`` never
+    hands cmd.exe a UNC starting directory it cannot use in the first
+    place. A non-UNC (drive-letter) *cwd* is returned unchanged — the
+    common case, where ``Popen``'s own ``cwd=`` already works correctly.
+    """
+    if cwd and _is_unc_path(cwd):
+        return f'pushd "{cwd}" && {command}', None
+    return command, (cwd or None)
+
+
+#: #3544: every kwarg :meth:`Win32Calls.launch`/:meth:`~Win32Calls.launch_in_terminal`
+#: must pass to ``subprocess.Popen`` so the launched ``cmd.exe`` (and whatever
+#: GUI-subsystem grandchild it execs) never inherits this *process's own*
+#: stdin/stdout/stderr handles.
+#:
+#: Without this, a plain ``subprocess.Popen(command, shell=True, cwd=...)``
+#: (no ``stdin=``/``stdout=``/``stderr=``) hands the child Python's own
+#: standard handles unchanged — on Windows that's an inheritance, not a
+#: dup/close-on-exec situation. When this `Win32Calls` lives inside the
+#: `win-native` bridge runner (:data:`coord.win_native_bridge._BRIDGE_RUNNER_SRC`,
+#: a Windows-side ``python -c ...`` whose own stdout is a pipe the WSL-side
+#: ``subprocess.run(capture_output=True)`` is reading), that pipe write-end
+#: handle gets duplicated into the launched GUI exe. A GUI-subsystem process
+#: (``vimcode.exe``) never exits on its own — a human closes the window, or a
+#: spec step does — so it holds that handle open indefinitely. A pipe's
+#: read end only sees EOF once *every* write-end handle is closed; with the
+#: orphaned GUI exe still holding one, the WSL-side read blocks past the
+#: whole bridge script's own completion, for the full
+#: ``bridge_timeout``, even though the bridge runner itself finished and
+#: exited normally. ``Get-Process`` then shows the launched exe still
+#: running, orphaned, after the bridge has already timed out and raised.
+#:
+#: Redirecting all three standard streams to ``DEVNULL`` severs that
+#: inheritance: the child gets its own private, already-closed-on-the-
+#: parent-side handles, never a dup of this process's own pipe — nothing in
+#: this driver ever reads a launched app's stdout/stderr (the whole point
+#: of `win-native` is observing the real OS/window state, not console
+#: text), so there is no output to lose.
+#:
+#: **Mechanism caveat (review finding on #3544, unresolved).** CPython's
+#: own Windows ``subprocess._execute_child`` computes ``bInheritHandles``
+#: as ``int(not close_fds)``, and ``close_fds`` defaults to ``True``
+#: (Python 3.7+) and is never overridden anywhere in this module — so by
+#: that code path alone, a bare ``Popen(command, shell=True, cwd=...)``
+#: with no ``stdin=``/``stdout=``/``stderr=`` should *already* pass
+#: ``bInheritHandles=False`` to ``CreateProcess``, meaning CPython's own
+#: handle-inheritance bookkeeping is probably *not* the actual leak
+#: mechanism. The hang itself is real and reproduced (``Get-Process``
+#: showing the launched exe still running minutes after a timed-out bridge
+#: call — see #3544's repro), but the likelier remaining culprit is
+#: something outside CPython's control for this specific topology: the
+#: bridge runner is itself started from WSL via ``wsl.exe``/interop, not a
+#: plain native parent process, and WSL interop's own console/job-object
+#: handling for the Windows-side process tree it creates can share or
+#: re-parent handles differently than a same-OS parent/child pair would.
+#:
+#: This redirect is still the right thing to do regardless of which exact
+#: mechanism turns out to be responsible: explicit ``DEVNULL`` handles are
+#: a private pair nothing downstream can keep open, so it closes off every
+#: plausible inheritance path at once rather than betting on one theory of
+#: the leak being correct. Treat it as the best available fix, **not** a
+#: hardware-confirmed root-cause diagnosis — it has not been re-run against
+#: the issue's own two repro scripts on a real WSL<->Windows pairing
+#: (dell64). ``tests/test_win_native_driver.py``'s
+#: ``TestLaunchPipeInheritanceRealSubprocess`` is the closest reproduction
+#: available without that hardware: a real (unmocked) OS pipe + subprocess
+#: tree showing a long-lived grandchild can hold a parent's un-redirected
+#: stdout pipe open past the parent's own exit, and that the real
+#: ``Win32Calls.launch`` no longer does so once its grandchild's handles
+#: are redirected.
+#:
+#: ``launch_in_terminal`` already passes ``creationflags=CREATE_NEW_CONSOLE``
+#: for its spawned process, which per Windows' own docs already gives the
+#: child its own console instead of sharing/inheriting the parent's — so
+#: applying this redirect there too is defensive-in-depth, not evidence
+#: that call site was equally exposed to the leak this fix targets.
+_NO_HANDLE_INHERITANCE: dict = {
+    "stdin": subprocess.DEVNULL,
+    "stdout": subprocess.DEVNULL,
+    "stderr": subprocess.DEVNULL,
+}
+
+
 class Win32Calls:
     """The real :class:`WinCalls` implementation — ``ctypes`` for window
     management, input injection, menu/hit-test probing and ``PrintWindow``;
@@ -789,7 +910,10 @@ class Win32Calls:
     # -- process lifecycle --
 
     def launch(self, command: str, cwd: str) -> int:
-        proc = subprocess.Popen(command, shell=True, cwd=cwd or None)
+        full_command, popen_cwd = _popen_command_and_cwd(command, cwd)
+        proc = subprocess.Popen(
+            full_command, shell=True, cwd=popen_cwd, **_NO_HANDLE_INHERITANCE,
+        )
         return proc.pid
 
     def launch_in_terminal(self, command: str, cwd: str, terminal_app: str) -> int:
@@ -798,8 +922,10 @@ class Win32Calls:
             full_command = f"wt.exe {command}"
         else:
             full_command = command
+        full_command, popen_cwd = _popen_command_and_cwd(full_command, cwd)
         proc = subprocess.Popen(
-            full_command, shell=True, cwd=cwd or None, creationflags=create_new_console,
+            full_command, shell=True, cwd=popen_cwd, creationflags=create_new_console,
+            **_NO_HANDLE_INHERITANCE,
         )
         return proc.pid
 

{code_coordinator-0.5.571 → code_coordinator-0.5.573}/tests/test_win_native_driver.py

@@ -16,6 +16,9 @@ from __future__ import annotations
 import base64
 import ctypes
 import os
+import select
+import subprocess
+import sys
 import time
 
 import pytest
@@ -28,6 +31,8 @@ from coord.win_native_driver import (
     WinNativeSpecError,
     Win32Calls,
     _find_a11y_match,
+    _is_unc_path,
+    _popen_command_and_cwd,
     _summarize_elements,
     _vkey_for,
     parse_native_spec,
@@ -1101,6 +1106,317 @@ class TestSessionAvailable:
         assert "OpenInputDesktop" in reason
 
 
+# ── UNC cwd (#3543) ──────────────────────────────────────────────────────────
+
+
+class TestIsUncPath:
+    def test_unc_path_is_detected(self) -> None:
+        assert _is_unc_path(r"\\wsl.localhost\Ubuntu-24.04\home\me\repo")
+
+    def test_drive_letter_path_is_not_unc(self) -> None:
+        assert not _is_unc_path(r"C:\Users\me\repo")
+
+    def test_empty_string_is_not_unc(self) -> None:
+        assert not _is_unc_path("")
+
+
+class TestPopenCommandAndCwd:
+    """#3543: `translate_to_windows_path` renders a WSL-hosted repo's `cwd`
+    as a UNC path (`\\wsl.localhost\\...`), but `cmd.exe` — what
+    `subprocess.Popen(..., shell=True)` always launches on Windows —
+    categorically refuses a UNC current directory at its own startup and
+    silently falls back to `%windir%`, breaking every relative path in the
+    launched command. These are the "fails first" unit-level reproduction
+    the issue's acceptance bar asks for: without the `pushd` fold-in below,
+    `_popen_command_and_cwd` would hand `Popen` a `cwd=` cmd.exe cannot
+    use."""
+
+    def test_unc_cwd_is_folded_into_a_pushd_prefix_and_cwd_is_cleared(self) -> None:
+        unc = r"\\wsl.localhost\Ubuntu-24.04\home\me\repo"
+        command, cwd = _popen_command_and_cwd("../target/app.exe sample.txt", unc)
+        assert command == f'pushd "{unc}" && ../target/app.exe sample.txt'
+        # Never hand cmd.exe a UNC `cwd=` — it refuses it regardless of
+        # what the command string itself does.
+        assert cwd is None
+
+    def test_drive_letter_cwd_passes_through_unchanged(self) -> None:
+        command, cwd = _popen_command_and_cwd("app.exe", r"C:\Users\me\repo")
+        assert command == "app.exe"
+        assert cwd == r"C:\Users\me\repo"
+
+    def test_empty_cwd_passes_through_as_none(self) -> None:
+        command, cwd = _popen_command_and_cwd("app.exe", "")
+        assert command == "app.exe"
+        assert cwd is None
+
+
+class TestWin32CallsLaunchAvoidsUncCwd:
+    """#3543: `Win32Calls.launch`/`launch_in_terminal` must never hand
+    `subprocess.Popen(..., shell=True)` a UNC `cwd=` — reproduces the exact
+    bridge-to-Windows shape (`run_native_spec_via_bridge` translates this
+    repo's WSL-hosted worktree to a UNC path and hands it to `launch`)
+    against a scripted fake `subprocess.Popen`, since the real cmd.exe
+    UNC-refusal behaviour can only be observed on a real Windows host."""
+
+    def test_launch_never_passes_a_unc_cwd_to_popen(self, monkeypatch) -> None:
+        unc = r"\\wsl.localhost\Ubuntu-24.04\home\me\repo"
+        calls = _make_win32_calls(_FakeUser32(), _FakeKernel32NoSession())
+        captured: dict = {}
+
+        class _FakeProc:
+            pid = 4242
+
+        def fake_popen(command, *, shell, cwd=None, **kwargs):
+            captured["command"] = command
+            captured["cwd"] = cwd
+            captured["shell"] = shell
+            return _FakeProc()
+
+        monkeypatch.setattr(
+            "coord.win_native_driver.subprocess.Popen", fake_popen,
+        )
+        pid = calls.launch("cd .smoke && ../target/app.exe sample.txt", unc)
+        assert pid == 4242
+        assert captured["shell"] is True
+        assert captured["cwd"] is None  # never a UNC cwd handed to Popen
+        assert captured["command"] == (
+            f'pushd "{unc}" && cd .smoke && ../target/app.exe sample.txt'
+        )
+
+    def test_launch_in_terminal_never_passes_a_unc_cwd_to_popen(
+        self, monkeypatch,
+    ) -> None:
+        unc = r"\\wsl.localhost\Ubuntu-24.04\home\me\repo"
+        calls = _make_win32_calls(_FakeUser32(), _FakeKernel32NoSession())
+        captured: dict = {}
+
+        class _FakeProc:
+            pid = 9999
+
+        def fake_popen(command, *, shell, cwd=None, **kwargs):
+            captured["command"] = command
+            captured["cwd"] = cwd
+            return _FakeProc()
+
+        monkeypatch.setattr(
+            "coord.win_native_driver.subprocess.Popen", fake_popen,
+        )
+        pid = calls.launch_in_terminal("app.exe", unc, "windows-terminal")
+        assert pid == 9999
+        assert captured["cwd"] is None
+        assert captured["command"] == f'pushd "{unc}" && wt.exe app.exe'
+
+    def test_launch_with_drive_letter_cwd_still_uses_popens_cwd(
+        self, monkeypatch,
+    ) -> None:
+        """Backward-compatible: the common (non-WSL) case keeps relying on
+        `Popen`'s own `cwd=`, not a `pushd` prefix."""
+        calls = _make_win32_calls(_FakeUser32(), _FakeKernel32NoSession())
+        captured: dict = {}
+
+        class _FakeProc:
+            pid = 1
+
+        def fake_popen(command, *, shell, cwd=None, **kwargs):
+            captured["command"] = command
+            captured["cwd"] = cwd
+            return _FakeProc()
+
+        monkeypatch.setattr(
+            "coord.win_native_driver.subprocess.Popen", fake_popen,
+        )
+        calls.launch("app.exe", r"C:\Users\me\repo")
+        assert captured["command"] == "app.exe"
+        assert captured["cwd"] == r"C:\Users\me\repo"
+
+
+class TestWin32CallsLaunchDoesNotInheritStdHandles:
+    """#3544: `Win32Calls.launch`/`launch_in_terminal` must never hand
+    `subprocess.Popen(..., shell=True)` its own inherited stdin/stdout/
+    stderr — reproduces the exact bridge shape (the Windows-side bridge
+    runner's own stdout is a pipe the WSL-side `subprocess.run(
+    capture_output=True)` is reading; without an explicit redirect here,
+    `cmd.exe` and the GUI exe it execs duplicate that same pipe handle and
+    never let it see EOF, so the bridge call hangs for the full
+    `bridge_timeout` and the launched exe is left orphaned — see
+    `coord.win_native_driver._NO_HANDLE_INHERITANCE` and
+    `coord.win_native_bridge.run_native_spec_via_bridge`). These two tests
+    only characterize *which kwargs* reach a scripted fake `Popen` — they
+    cannot demonstrate the redirect actually prevents the hang.
+    `TestLaunchPipeInheritanceRealSubprocess` below does that with a real,
+    unmocked OS pipe + subprocess tree; the real handle-inheritance hang on
+    the exact Windows/WSL topology the issue reports can still only be
+    observed on a real WSL<->Windows pairing (confirmed on dell64 per
+    #3544's repro, not re-run against this fix)."""
+
+    def test_launch_redirects_all_three_std_handles_to_devnull(
+        self, monkeypatch,
+    ) -> None:
+        calls = _make_win32_calls(_FakeUser32(), _FakeKernel32NoSession())
+        captured: dict = {}
+
+        class _FakeProc:
+            pid = 4242
+
+        def fake_popen(command, *, shell, cwd=None, **kwargs):
+            captured.update(kwargs)
+            return _FakeProc()
+
+        monkeypatch.setattr(
+            "coord.win_native_driver.subprocess.Popen", fake_popen,
+        )
+        calls.launch("vimcode.exe sample.txt", r"C:\Users\me\repo")
+        assert captured.get("stdin") is subprocess.DEVNULL
+        assert captured.get("stdout") is subprocess.DEVNULL
+        assert captured.get("stderr") is subprocess.DEVNULL
+
+    def test_launch_in_terminal_redirects_all_three_std_handles_to_devnull(
+        self, monkeypatch,
+    ) -> None:
+        calls = _make_win32_calls(_FakeUser32(), _FakeKernel32NoSession())
+        captured: dict = {}
+
+        class _FakeProc:
+            pid = 9999
+
+        def fake_popen(command, *, shell, cwd=None, **kwargs):
+            captured.update(kwargs)
+            return _FakeProc()
+
+        monkeypatch.setattr(
+            "coord.win_native_driver.subprocess.Popen", fake_popen,
+        )
+        calls.launch_in_terminal("vimcode.exe", r"C:\Users\me\repo", "windows-terminal")
+        assert captured.get("stdin") is subprocess.DEVNULL
+        assert captured.get("stdout") is subprocess.DEVNULL
+        assert captured.get("stderr") is subprocess.DEVNULL
+
+
+class TestLaunchPipeInheritanceRealSubprocess:
+    """#3544 review follow-up: a real, unmocked reproduction of the exact
+    EOF-blocking mechanism the issue describes, using real OS pipes and a
+    real subprocess tree instead of a scripted fake `Popen`.
+
+    This is the closest in-repo stand-in for the issue's own mandatory
+    acceptance line ("a Tier-1 shared conformance scenario or a Tier-2
+    smoke-spec step that fails first, covering this exact behaviour") that
+    this repo can host on its own: the actual Tier-2 `win-native` smoke
+    spec (`tests/smoke-spec/win-gui.yaml`-style) lives in the *app* repo
+    (vimcode) that declares the `win-native` acceptance driver, not here —
+    `coord` only ships the driver engine, and this worktree runs on Linux
+    with no real Windows/WSL pairing available. What *is* reproducible
+    here, with no Windows dependency at all, is the general OS mechanism:
+    an un-redirected standard handle can be inherited by a long-lived
+    child and keep a reader from ever seeing EOF, independent of platform.
+    That is the behaviour `Win32Calls.launch` must avoid, whatever the
+    exact Win32-side inheritance rule turns out to be (see the review
+    discussion captured in `_NO_HANDLE_INHERITANCE`'s own docstring, which
+    is honest that the Windows mechanism remains unconfirmed on real
+    hardware).
+
+    - `test_shell_true_with_no_redirect_leaks_stdout_to_grandchild`
+      reproduces the pre-fix shape in isolation (a bare
+      `subprocess.Popen(cmd, shell=True)` with no stdin=/stdout=/stderr=,
+      exactly what `Win32Calls.launch` did before #3544) and shows it
+      really does let a long-lived grandchild hold the runner's own stdout
+      pipe open past the runner's own exit — i.e. this test *fails first*
+      against the pre-fix code shape (and would fail again if someone
+      reintroduced it).
+    - `test_real_launch_does_not_leak_stdout_to_grandchild` drives the
+      actual production `Win32Calls.launch` (called unbound — it never
+      touches `self`) through the identical pipe setup and asserts EOF
+      arrives promptly even with its own long-lived grandchild still
+      running: revert `_NO_HANDLE_INHERITANCE` and this test fails the
+      same way the one above does.
+    """
+
+    @staticmethod
+    def _read_until_eof_or_timeout(fd: int, timeout: float) -> tuple[bytes, bool]:
+        """Read *fd* until EOF (empty read) or *timeout* seconds elapse.
+
+        Returns ``(data_read, hit_eof)`` — ``hit_eof`` is `False` when the
+        deadline passed with the pipe's write end still open (some writer
+        — e.g. a leaked grandchild — is still holding it), `True` once a
+        zero-length read confirms every write end has closed.
+        """
+        deadline = time.monotonic() + timeout
+        data = b""
+        while True:
+            remaining = deadline - time.monotonic()
+            if remaining <= 0:
+                return data, False
+            ready, _, _ = select.select([fd], [], [], remaining)
+            if not ready:
+                continue
+            chunk = os.read(fd, 4096)
+            if not chunk:
+                return data, True
+            data += chunk
+
+    def test_shell_true_with_no_redirect_leaks_stdout_to_grandchild(self) -> None:
+        """Pre-fix shape in isolation: a bare `Popen(cmd, shell=True)` with
+        no std-handle redirection really does let a long-lived grandchild
+        hold the parent's own stdout pipe open past the parent's exit."""
+        r, w = os.pipe()
+        try:
+            runner = subprocess.Popen(
+                [
+                    sys.executable, "-c",
+                    "import subprocess, sys\n"
+                    "subprocess.Popen('sleep 2', shell=True)\n"
+                    "sys.stdout.write('runner-done\\n')\n"
+                    "sys.stdout.flush()\n",
+                ],
+                stdout=w,
+            )
+            os.close(w)
+            w = -1
+            assert runner.wait(timeout=10) == 0
+            data, hit_eof = self._read_until_eof_or_timeout(r, timeout=0.8)
+            assert data == b"runner-done\n"
+            assert not hit_eof, (
+                "expected the un-redirected grandchild to still be holding "
+                "the pipe open at this point — if this starts passing, the "
+                "repro no longer demonstrates the mechanism #3544 reports"
+            )
+        finally:
+            if w != -1:
+                os.close(w)
+            os.close(r)
+
+    def test_real_launch_does_not_leak_stdout_to_grandchild(self) -> None:
+        """The actual fix: the real `Win32Calls.launch` (called unbound —
+        it never touches `self`) must not let its own long-lived `sleep`
+        grandchild hold the runner's stdout pipe open."""
+        r, w = os.pipe()
+        try:
+            runner = subprocess.Popen(
+                [
+                    sys.executable, "-c",
+                    "import sys\n"
+                    "from coord.win_native_driver import Win32Calls\n"
+                    "Win32Calls.launch(None, 'sleep 2', '.')\n"
+                    "sys.stdout.write('runner-done\\n')\n"
+                    "sys.stdout.flush()\n",
+                ],
+                stdout=w,
+            )
+            os.close(w)
+            w = -1
+            assert runner.wait(timeout=10) == 0
+            data, hit_eof = self._read_until_eof_or_timeout(r, timeout=0.8)
+            assert data == b"runner-done\n"
+            assert hit_eof, (
+                "pipe never hit EOF while the launched grandchild was "
+                "still alive — Win32Calls.launch is leaking a standard "
+                "handle to it again (#3544)"
+            )
+        finally:
+            if w != -1:
+                os.close(w)
+            os.close(r)
+
+
 class TestImportUia:
     def test_missing_comtypes_raises_actionable_error(self, monkeypatch) -> None:
         import builtins