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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.572
+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.572 → 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.572
+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.572 → code_coordinator-0.5.573}/code_coordinator.egg-info/scm_version.json

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

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

@@ -810,6 +810,79 @@ def _popen_command_and_cwd(command: str, cwd: str) -> tuple[str, str | 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``;
@@ -838,7 +911,9 @@ class Win32Calls:
 
     def launch(self, command: str, cwd: str) -> int:
         full_command, popen_cwd = _popen_command_and_cwd(command, cwd)
-        proc = subprocess.Popen(full_command, shell=True, cwd=popen_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:
@@ -850,6 +925,7 @@ class Win32Calls:
         full_command, popen_cwd = _popen_command_and_cwd(full_command, cwd)
         proc = subprocess.Popen(
             full_command, shell=True, cwd=popen_cwd, creationflags=create_new_console,
+            **_NO_HANDLE_INHERITANCE,
         )
         return proc.pid
 

{code_coordinator-0.5.572 → 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
@@ -1227,6 +1230,193 @@ class TestWin32CallsLaunchAvoidsUncCwd:
         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