davinci-resolve-mcp 2.70.1 → 2.70.3

package/CHANGELOG.md

@@ -2,6 +2,130 @@
 
 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
+healthy in-app bridge. Reported in issue #109 by @alpaolo.
+
+### The bug
+
+The panel runs as a separate process from the MCP server and has its own Resolve
+connector. That connector returned as soon as `import DaVinciResolveScript`
+failed:
+
+```python
+try:
+    import DaVinciResolveScript as dvr_script
+except Exception as exc:
+    return None, f"Resolve scripting API unavailable: {exc}"
+```
+
+On the free edition that import is exactly what fails — Blackmagic's module ships
+with the installer, not the App Store build, so there is no
+`Developer/Scripting/Modules` tree to import from. The panel returned there,
+before ever calling `connect_resolve`, whose entire purpose is that it accepts
+`None` in bridge mode:
+
+> `dvr_script` may be None in bridge mode: the bridge does not need Blackmagic's
+> module at all, which is precisely why it reaches editions the module cannot.
+
+So the reporter saw the bridge listening, the MCP server connected, and the panel
+insisting "Resolve unavailable" — all at the same time, all correct.
+
+`_try_connect` in `src/server.py` already carried this guard, with a comment
+recording the same diagnosis from when it bit the server. The panel's connector
+was missed. That makes it the third connector overlooked when a transport was
+added, after the network-scripting one in v2.64.0.
+
+### The fix
+
+The panel now consults the bridge first and treats both the environment setup and
+the module import as optional when it is enabled — the same ordering the MCP
+server uses.
+
+The not-connected message no longer assumes Studio. It used to send every reader
+to "open Resolve Studio with a project loaded", which is poor advice for a
+free-edition user, since free is the one edition external scripting refuses by
+design. It now names the fix that fits the situation, and says something
+different depending on whether the bridge is enabled.
+
+### Windows bridge: `%PROGRAMDATA%` now confirmed
+
+v2.70.1 shipped Windows script paths unverified. The #109 report was made on free
+21.0.1.11 with the bridge installed, listed and serving from `%PROGRAMDATA%`, so
+that half is now confirmed rather than assumed. `%APPDATA%` remains untested.
+
 ## What's New in v2.70.1
 
 Windows support for the free-edition in-app bridge, and the end of doctor.py's

package/README.md

@@ -1,6 +1,6 @@
 # DaVinci Resolve MCP Server
 
-[![Version](https://img.shields.io/badge/version-2.70.1-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)
@@ -57,11 +57,16 @@ interpreters are not detected, and the script silently never appears in the
 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. **Windows paths were
-added in v2.70.1 (issue #106) and have not yet been confirmed on Windows
-hardware** — the installer targets the `%APPDATA%` and `%PROGRAMDATA%` script
-folders Blackmagic documents, but whether Resolve lists the bridge from them is
-unverified. Reports welcome.
+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; 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,20 @@ 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 is unconfirmed.** The `%APPDATA%`/`%PROGRAMDATA%` script folders are
-  targeted as of v2.70.1, but no Windows machine has verified that Resolve lists
-  the bridge from them. 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.
 - The in-Resolve runtime is a **copy taken at install time**. After changing the
   repository, re-run the installer and then ask the running bridge to reload —
   it re-imports from disk in place, so Resolve does not need restarting.

package/install.py

@@ -36,7 +36,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "2.70.1"
+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.1",
+  "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/analysis_dashboard.py

@@ -11953,9 +11953,33 @@ def _serialize_resolve(func):
     return wrapper
 
 
+def _bridge_requested() -> bool:
+    """Has the operator asked for the in-app bridge?
+
+    Read at call time rather than at import, so a panel started before the
+    variable was set still honours it.
+    """
+    try:
+        from src.utils import resolve_bridge_client
+
+        return resolve_bridge_client.bridge_enabled()
+    except Exception:  # pragma: no cover - the client is optional
+        return False
+
+
 def _connect_resolve_read_only() -> Tuple[Any, Optional[str]]:
     global _RESOLVE_ENV_READY
     with _RESOLVE_API_LOCK:
+        # Blackmagic's module ships with the *installer*, not the App Store
+        # build, so a free-edition machine has no Developer/Scripting/Modules
+        # tree and both the environment setup and the import fail. Returning
+        # here made the control panel unreachable on exactly the configuration
+        # the bridge exists for: the MCP server connects fine over the bridge
+        # while the panel — a separate process with its own connector — reports
+        # "Resolve unavailable". `connect_resolve` accepts None in bridge mode,
+        # and this returned before ever calling it (server.py:_try_connect
+        # carries the same guard for the same reason).
+        bridge_on = _bridge_requested()
         # Environment + sys.path setup is pure overhead and never goes stale, so
         # run it once per process rather than on every connection.
         if not _RESOLVE_ENV_READY:
@@ -11968,20 +11992,41 @@ def _connect_resolve_read_only() -> Tuple[Any, Optional[str]]:
                         sys.path.append(candidate)
                 _RESOLVE_ENV_READY = True
             except Exception as exc:
-                return None, f"Resolve scripting API unavailable: {exc}"
+                if not bridge_on:
+                    return None, f"Resolve scripting API unavailable: {exc}"
+        dvr_script = None
         try:
-            import DaVinciResolveScript as dvr_script  # type: ignore
+            import DaVinciResolveScript as _dvr_script  # type: ignore
+
+            dvr_script = _dvr_script
         except Exception as exc:
-            return None, f"Resolve scripting API unavailable: {exc}"
+            if not bridge_on:
+                return None, f"Resolve scripting API unavailable: {exc}"
         try:
             resolve = connect_resolve(dvr_script)
         except Exception as exc:
             return None, f"Resolve connection failed: {exc}"
         if resolve is None:
-            return None, "DaVinci Resolve is not connected. Open Resolve Studio with a project loaded."
+            return None, _not_connected_message(bridge_on)
         return resolve, None
 
 
+def _not_connected_message(bridge_on: bool) -> str:
+    """Name the fix that applies, rather than assuming Studio.
+
+    The old text sent every reader to "open Resolve Studio", which is wrong
+    advice for a free-edition user — the edition external scripting refuses by
+    design, and the one the bridge exists to reach.
+    """
+    if bridge_on:
+        return ("The in-app bridge is enabled but not answering. In Resolve, run "
+                "Workspace > Scripts > resolve_bridge; launching Resolve cannot start it.")
+    return ("DaVinci Resolve is not connected. On Studio, enable Preferences > General > "
+            "'External scripting using' = Local. On the free edition, install the in-app "
+            "bridge, run Workspace > Scripts > resolve_bridge, and set "
+            "DAVINCI_RESOLVE_BRIDGE=1.")
+
+
 @_serialize_resolve
 def _current_resolve_project_id() -> Tuple[Optional[str], Optional[str]]:
     """(project_id, error) for the currently-open Resolve project.

package/src/granular/common.py

@@ -85,7 +85,7 @@ if not logging.getLogger().handlers:
         handlers=[logging.StreamHandler()],
     )
 
-VERSION = "2.70.1"
+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.1"
+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.