davinci-resolve-mcp 2.70.2 → 2.70.3

package/CHANGELOG.md

@@ -2,6 +2,77 @@
 
 Release history for the DaVinci Resolve MCP Server. The latest release is summarized in the root README; older entries live here to keep the README focused.
 
+## What's New in v2.70.3
+
+The free-edition bridge could never notice Resolve exiting on Windows, so it
+orphaned itself and blocked the next session. Reported in issue #112 by
+@ZontarLives, with a self-contained repro.
+
+### The bug
+
+`serve()` detected host exit with a single test:
+
+```python
+if os.getppid() != expected_parent:
+    break
+```
+
+That is a POSIX signal. When a parent dies, POSIX reparents the orphan to init
+and the value changes. **Windows does not reparent** — the parent pid is a
+static field in the process record, so `os.getppid()` returns the dead parent's
+pid forever and the check can never fire.
+
+The consequence is not a cosmetic leak. The orphaned `fuscript.exe` keeps port
+49632 and keeps accepting connections while holding a dead `resolve` handle, so
+the next Resolve session's bridge cannot bind, and the client sees:
+
+```
+bridge_timeout: Resolve did not answer in time - check for an open modal dialog,
+which blocks its scripting API entirely
+```
+
+against a socket that `Get-NetTCPConnection` reports as healthily `LISTENING`.
+Every surface-level check passes and the suggested cause is a red herring, which
+is what made it expensive to diagnose.
+
+### The fix
+
+Liveness is now asked directly instead of inferred from a pid changing:
+
+- `parent_has_exited()` keeps the reparent test as the fast path where it works,
+  then checks whether the parent pid still resolves to a live process, then
+  whether that process still name-matches `PARENT_MARKERS`. The last step also
+  catches pid reuse, which the old check would have misread as "Resolve exited".
+- On Windows liveness comes from `OpenProcess` + `WaitForSingleObject` via
+  `ctypes`. Only "no such process" counts as death: access-denied and every
+  other error are *unknown*, and unknown never ends the session — the module's
+  standing rule is that a bridge which exits early is worse than one that
+  lingers.
+- `_process_name()` gained a Windows branch (`QueryFullProcessImageNameW`). It
+  previously tried `/proc` then `ps`, so it returned an empty string on every
+  Windows machine. `scripts/resolve_bridge_probe.py` gets the same treatment.
+
+Binding failures now name the likely cause and the way out, rather than
+surfacing a bare "address already in use" that sends people to check firewalls.
+
+The Windows branch is injectable so it is tested off Windows — a constant
+`getppid` plus a simulated liveness answer. The platform difference is precisely
+what kept this invisible to everyone developing on macOS or Linux.
+
+### Also confirmed
+
+`%APPDATA%` now joins `%PROGRAMDATA%` as a verified Windows bridge location; the
+#112 report served reads from it against free 21.0.3.7. README and `docs/SKILL.md`
+updated, along with guidance that a bridge which stops answering while
+`LISTENING` is a stale process rather than a modal dialog.
+
+### Also in this release
+
+Two offline guard tests built their "not a temp path" target from `os.getcwd()`,
+which failed — and wrote a real `look.cube` into the working directory — whenever
+the suite ran from a directory under `/tmp`. `tests/_paths.py` makes them
+independent of where the suite runs.
+
 ## What's New in v2.70.2
 
 The control panel could never reach the free edition, even with a perfectly

package/README.md

@@ -1,6 +1,6 @@
 # DaVinci Resolve MCP Server
 
-[![Version](https://img.shields.io/badge/version-2.70.2-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.70.3-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-34%20(341%20full)-blue.svg)](#server-modes)
@@ -58,10 +58,15 @@ menu. A Lua canary is installed alongside so you can tell that apart from a
 wrong folder.
 
 Validated on free 21.0.3.7 and Studio 19.1.3.7, both macOS. The Windows paths
-added in v2.70.1 (issue #106) shipped unverified; a report on free 21.0.1.11
-(issue #109) has since shown the bridge installing, listing and serving from
-`%PROGRAMDATA%` on Windows, so that path is now confirmed rather than assumed.
-`%APPDATA%` remains untested. Reports welcome.
+added in v2.70.1 (issue #106) shipped unverified; reports on free 21.0.1.11
+(issue #109) and free 21.0.3.7 (issue #112) have since shown the bridge
+installing, listing and serving from **both** `%PROGRAMDATA%` and `%APPDATA%` on
+Windows 11, so those paths are now confirmed rather than assumed.
+
+Note that the bridge holds its port for as long as it serves. Before v2.70.3 a
+Windows bridge could outlive Resolve and block the next session's listener; if
+you are on an older build and a bridge stops answering, check for a stale
+`fuscript.exe` still holding the port.
 
 This is the documented in-app path, not a licence circumvention, but Blackmagic
 could close it — treat it as a supported-until-it-is-not tier. Loopback only,

package/docs/SKILL.md

@@ -33,11 +33,17 @@ work unchanged. Two things to know when diagnosing it:
   Lua canary, which always lists, so "Python not detected" is distinguishable
   from "wrong folder". The preflight is macOS-only — off macOS Resolve finds
   Python by other means, and running the check there was a false alarm (#106).
-- **Windows: `%PROGRAMDATA%` confirmed, `%APPDATA%` still not.** Both script
-  folders have been targeted since v2.70.1; a free 21.0.1.11 report (#109) has
-  since shown Resolve listing and serving the bridge from `%PROGRAMDATA%`. If a
-  user reports the menu entry missing on Windows, ask whether the Lua canary
-  lists — that separates "wrong folder" from "Python not detected" there too.
+- **Windows: both script folders confirmed.** `%PROGRAMDATA%` (#109) and
+  `%APPDATA%` (#112) have each been shown serving the bridge on Windows 11 free
+  builds. If a user reports the menu entry missing on Windows, ask whether the
+  Lua canary lists — that separates "wrong folder" from "Python not detected".
+- **A bridge that stops answering while its socket is `LISTENING` is a stale
+  process, not a modal dialog.** Before v2.70.3 the Windows bridge could never
+  detect Resolve exiting (`os.getppid()` does not change there), so it outlived
+  Resolve holding the port and answering with a dead handle — and the
+  `bridge_timeout` message blamed a modal dialog. On any build, the way out is
+  the `shutdown` operation (`BridgeClient.bridge_shutdown()`); killing the
+  process is the fallback, not the first move.
 - The **control panel connects over the bridge too** (fixed in v2.70.2). It runs
   as a separate process with its own connector, so a panel that reports "Resolve
   unavailable" while tool calls work is a panel-side bug, not a broken bridge.

package/install.py

@@ -36,7 +36,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "2.70.2"
+VERSION = "2.70.3"
 # Only hard floor: mcp[cli] requires Python 3.10+. There is no upper bound —
 # Resolve's scripting bridge loads into newer interpreters on recent builds
 # (Python 3.14 verified against Resolve Studio 20.3.2). Older Resolve builds

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "davinci-resolve-mcp",
-  "version": "2.70.2",
+  "version": "2.70.3",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/scripts/resolve_bridge_probe.py

@@ -35,6 +35,26 @@ PARENT_MARKERS = ("resolve", "fuscript", "fusion")
 
 def process_name(pid):
     """Best-effort process name; empty string when it cannot be read."""
+    if os.name == "nt":
+        # Windows has neither /proc nor ps, so the probe reported an empty
+        # parent name on every Windows machine (issue #112).
+        try:
+            import ctypes
+
+            kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
+            handle = kernel32.OpenProcess(0x1000, False, int(pid))
+            if not handle:
+                return ""
+            try:
+                size = ctypes.c_ulong(260)
+                buf = ctypes.create_unicode_buffer(size.value)
+                if not kernel32.QueryFullProcessImageNameW(handle, 0, buf, ctypes.byref(size)):
+                    return ""
+                return os.path.basename(buf.value)
+            finally:
+                kernel32.CloseHandle(handle)
+        except Exception:
+            return ""
     try:  # Linux
         with open("/proc/%d/comm" % pid) as handle:
             return handle.read().strip()

package/src/granular/common.py

@@ -85,7 +85,7 @@ if not logging.getLogger().handlers:
         handlers=[logging.StreamHandler()],
     )
 
-VERSION = "2.70.2"
+VERSION = "2.70.3"
 logger = logging.getLogger("davinci-resolve-mcp")
 logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
 logger.info(f"Detected platform: {get_platform()}")

package/src/server.py

@@ -11,7 +11,7 @@ Usage:
     python src/server.py --full       # Start the 341-tool granular server instead
 """
 
-VERSION = "2.70.2"
+VERSION = "2.70.3"
 
 import base64
 import os

package/src/utils/resolve_bridge.py

@@ -204,6 +204,8 @@ def _host_model(
 
 def _process_name(pid: int) -> str:
     """Best-effort process name; empty string when it cannot be read."""
+    if os.name == "nt":
+        return _windows_process_name(pid)
     try:  # Linux
         with open(f"/proc/{pid}/comm", "r", encoding="utf-8") as handle:
             return handle.read().strip()
@@ -221,6 +223,126 @@ def _process_name(pid: int) -> str:
         return ""
 
 
+def _windows_process_name(pid: int) -> str:  # pragma: no cover - exercised on Windows
+    """Image name for a pid via Win32, or "" when it cannot be read.
+
+    ctypes rather than `tasklist`: the bridge polls this, and spawning a console
+    process every second inside Resolve is both slow and visible.
+    """
+    try:
+        import ctypes
+        from ctypes import wintypes
+
+        kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
+        handle = kernel32.OpenProcess(_WIN_PROCESS_QUERY_LIMITED_INFORMATION, False, int(pid))
+        if not handle:
+            return ""
+        try:
+            size = wintypes.DWORD(260)
+            buf = ctypes.create_unicode_buffer(size.value)
+            if not kernel32.QueryFullProcessImageNameW(handle, 0, buf, ctypes.byref(size)):
+                return ""
+            return os.path.basename(buf.value)
+        finally:
+            kernel32.CloseHandle(handle)
+    except Exception:
+        return ""
+
+
+# Win32 constants used for parent-liveness detection.
+_WIN_PROCESS_QUERY_LIMITED_INFORMATION = 0x1000
+_WIN_SYNCHRONIZE = 0x00100000
+_WIN_WAIT_OBJECT_0 = 0x0
+_WIN_WAIT_TIMEOUT = 0x102
+_WIN_ERROR_INVALID_PARAMETER = 87
+
+
+def _process_is_alive(pid: int) -> Optional[bool]:
+    """True / False / None when it genuinely cannot be determined.
+
+    `None` matters: this module's standing rule is that a bridge which exits
+    early is worse than one that lingers, so an undeterminable answer must not
+    be allowed to read as "the parent died".
+    """
+    if not pid or pid <= 0:
+        return None
+    if os.name == "nt":  # pragma: no cover - exercised on Windows
+        try:
+            import ctypes
+
+            kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
+            access = _WIN_SYNCHRONIZE | _WIN_PROCESS_QUERY_LIMITED_INFORMATION
+            handle = kernel32.OpenProcess(access, False, int(pid))
+            if not handle:
+                # Only "no such process" is proof of death. Access-denied and
+                # everything else are unknown — a bridge must not quit because
+                # it could not open a handle.
+                return False if ctypes.get_last_error() == _WIN_ERROR_INVALID_PARAMETER else None
+            try:
+                status = kernel32.WaitForSingleObject(handle, 0)
+                if status == _WIN_WAIT_OBJECT_0:
+                    return False  # signalled == exited
+                if status == _WIN_WAIT_TIMEOUT:
+                    return True
+                return None
+            finally:
+                kernel32.CloseHandle(handle)
+        except Exception:
+            return None
+    try:
+        os.kill(pid, 0)
+        return True
+    except ProcessLookupError:
+        return False
+    except PermissionError:
+        return True  # exists, owned by someone else
+    except OSError:
+        return None
+
+
+def parent_has_exited(expected_pid: int, expected_name: str = "",
+                      *, getppid: Callable[[], int] = os.getppid,
+                      is_alive: Callable[[int], Optional[bool]] = _process_is_alive,
+                      name_of: Callable[[int], str] = _process_name) -> bool:
+    """Has the Resolve that launched this script gone away?
+
+    `os.getppid() != expected_pid` is the POSIX signal — an orphan is reparented
+    to init, so the value changes. **Windows does not reparent.** The parent pid
+    is a static field in the process record, so `getppid()` returns the dead
+    parent's pid forever and a check written that way can never fire: the bridge
+    outlives Resolve, keeps its port, and answers with a dead handle. The next
+    session's bridge then cannot bind, and the client sees a timeout against a
+    socket that is `LISTENING` — every surface-level check passes (issue #112).
+
+    So liveness is asked directly, and reparenting is kept as the fast path
+    where it works. The name check additionally catches pid reuse, which the
+    reparent test would misread as "Resolve exited".
+
+    Unknown liveness is never treated as death, per the module's standing rule.
+    """
+    try:
+        if getppid() != expected_pid:
+            return True
+    except Exception:  # pragma: no cover - defensive
+        pass
+    alive = is_alive(expected_pid)
+    if alive is False:
+        return True
+    if alive is None:
+        return False
+    # Pid reuse: the number is alive but now belongs to something else. Only
+    # usable when the ORIGINAL name looked like Resolve — otherwise there is no
+    # baseline to have drifted from. `_host_model` documents that the parent
+    # name is routinely empty or non-matching under the App Store sandbox, where
+    # `ps` on another process is blocked; treating that as death would kill the
+    # bridge on its first poll, on the exact edition it exists for.
+    if expected_name and any(m in expected_name.lower() for m in PARENT_MARKERS):
+        current = (name_of(expected_pid) or "").lower()
+        if current and not any(marker in current for marker in PARENT_MARKERS):
+            return True
+    return False
+
+
 def probe_host_model() -> Dict[str, Any]:
     """Report the host model without starting a listener.
 
@@ -502,7 +624,23 @@ class Bridge:
         return held == MAX_CONCURRENT_CONNECTIONS
 
     def start(self) -> "Bridge":
-        self._server = _Server((self.config["host"], self.config["port"]), self)
+        host, port = self.config["host"], self.config["port"]
+        try:
+            self._server = _Server((host, port), self)
+        except OSError as exc:
+            # An orphaned bridge from a previous session is the likely cause,
+            # and a bare "address already in use" sends people looking at
+            # firewalls. Say what is actually holding the port and how to clear
+            # it — the alternative is a LISTENING socket answering with a dead
+            # Resolve handle, which reads as a broken install (issue #112).
+            raise BridgeConfigError(
+                f"cannot listen on {host}:{port} — {exc}. Another bridge is probably still "
+                "running from an earlier Resolve session. Ask it to stop (send the `shutdown` "
+                "operation, or `resolve_bridge_client.BridgeClient(...).bridge_shutdown()`), or "
+                "end the stale process: Windows `Get-NetTCPConnection -LocalPort "
+                f"{port} | Select-Object OwningProcess` then `Stop-Process -Id <pid>`; "
+                f"macOS/Linux `lsof -ti tcp:{port} | xargs kill`."
+            ) from exc
         self._thread = threading.Thread(target=self._server.serve_forever, name="ResolveBridge", daemon=True)
         self._thread.start()
         return self
@@ -518,7 +656,8 @@ class Bridge:
     def port(self) -> int:
         return self._server.server_address[1] if self._server else self.config["port"]
 
-    def serve(self, *, poll_seconds: float = 1.0, host_model: Optional[Dict[str, Any]] = None) -> Dict[str, Any]:
+    def serve(self, *, poll_seconds: float = 1.0, host_model: Optional[Dict[str, Any]] = None,
+              parent_exited: Optional[Callable[[int, str], bool]] = None) -> Dict[str, Any]:
         """Start, then block or return according to the detected host model.
 
         Returns immediately in-process (the caller keeps a reference alive);
@@ -535,6 +674,10 @@ class Bridge:
             model["stop_reason"] = None
             return model
         expected_parent = model["parent_pid"]
+        expected_name = model.get("parent_name") or ""
+        # Injectable so the Windows branch is testable off Windows — the bug
+        # this replaced was invisible on the maintainer's platform.
+        host_exited = parent_exited or parent_has_exited
         reason = "resolve_exited"
         try:
             while True:
@@ -544,7 +687,7 @@ class Bridge:
                 if self._thread is None or not self._thread.is_alive():
                     reason = "listener_died"
                     break
-                if os.getppid() != expected_parent:
+                if host_exited(expected_parent, expected_name):
                     break
                 # Waiting on the event rather than joining the thread makes a
                 # requested stop immediate instead of up to `poll_seconds` late.