davinci-resolve-mcp 2.70.0 → 2.70.2

package/CHANGELOG.md

@@ -2,6 +2,145 @@
 
 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.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
+macOS-only path assumptions. Reported in issue #106 by @kacemmosbah8-afk.
+
+### The bug
+
+`script_targets()` in `scripts/install_resolve_bridge.py` enumerated macOS and
+Linux candidates only. There was no Windows branch at all, so the candidate list
+came back empty on every Windows machine and the installer exited with:
+
+```
+No writable DaVinci Resolve Scripts/Utility folder found. Is Resolve installed?
+```
+
+on installs where Resolve was demonstrably present. Since the in-app bridge is
+the *only* route to the free edition — external scripting is Studio-gated by
+Blackmagic — Windows free-edition users had no working path to this server at
+all. The bridge shipped in v2.68.0; it has been macOS/Linux-only that whole time.
+
+Windows now targets the two Scripts/Utility trees Blackmagic documents, per-user
+first because `%PROGRAMDATA%` typically needs an elevated prompt:
+
+- `%APPDATA%\Blackmagic Design\DaVinci Resolve\Support\Fusion\Scripts\Utility`
+- `%PROGRAMDATA%\Blackmagic Design\DaVinci Resolve\Fusion\Scripts\Utility`
+
+Three traps came out of implementing that, each now pinned by a test:
+
+- **The per-user tree carries a `Support` segment the all-users tree does not.**
+  They are not one layout under two roots; deriving either from the other lands
+  in a folder Resolve never scans.
+- **Blackmagic's own README writes the per-user root as `%APPDATA%\Roaming\...`,
+  which is wrong** — `%APPDATA%` already *is* `...\AppData\Roaming`. Transcribing
+  it verbatim yields `AppData\Roaming\Roaming\...`: a real, creatable folder that
+  is silently never read.
+- **Resolve does not create its `Fusion\Scripts` tree until a script is
+  installed**, so gating on that tree existing — or on its parent being writable
+  — skips a fresh free-edition install, the exact build the bridge exists for.
+  The candidates are gated on Resolve's product folder instead, mirroring how the
+  macOS sandbox container is handled.
+
+`install()` no longer aborts when one target is unwritable. The `%PROGRAMDATA%`
+tree needs elevation, and Windows `os.access(W_OK)` reports the read-only flag
+rather than the ACL, so it cannot be screened out in advance — without this, the
+newly added candidate would have crashed the installer on every non-elevated
+Windows account *after* it had already succeeded into the per-user tree. Skips
+are reported in `warnings`; only a clean sweep is fatal, and that error now names
+the folders and the reason instead of asking whether Resolve is installed.
+
+### The macOS framework-Python alarm was firing off macOS
+
+`python_preflight()` looked for a framework Python under `/Library/Frameworks`,
+a path that cannot exist on Windows or Linux — so it always found nothing and
+emitted the macOS remediation, telling the reporter (running a working python.org
+3.12.9) to install the Python they already had. Linux had the same false alarm.
+The check is now macOS-only. The Lua canary still ships everywhere, so a genuine
+enumeration failure stays diagnosable.
+
+### doctor.py was macOS-only too
+
+`scripts/doctor.py` hardcoded macOS defaults for `RESOLVE_APP`,
+`RESOLVE_SCRIPT_API` and `RESOLVE_SCRIPT_LIB`. Run standalone — that is, without
+the environment variables the npm/`install.py` flow injects — it reported four
+`[FAIL]` lines naming a `.app` bundle and `fusionscript.so` on a Windows 11
+machine that had neither, while `install.py` detected that same install
+correctly. Two tables describing one thing, one of them platform-blind. Linux was
+equally affected.
+
+doctor now selects per-platform candidates, and picks the first that exists so
+the reported path matches reality. macOS values are byte-identical to before.
+A new `tests/test_doctor_paths.py` drift guard asserts every path doctor names
+also appears in `install.py`'s `RESOLVE_PATHS`, so the two cannot diverge again.
+Claude Desktop's config path is now MSIX-aware on Windows as well, matching the
+issue #93 fix that `install.py` already had.
+
+### Scope — what is and is not verified
+
+The path construction is unit-tested, and a simulated Windows run exercises the
+installer end to end. **No Windows hardware has confirmed that Resolve actually
+lists the bridge from these folders.** The reporter verified the folders exist
+and are writable; issue #104 is precedent that "the folder exists" and "Resolve
+reads it" are different claims. The README and `docs/SKILL.md` say so plainly
+rather than implying Windows is a supported, tested tier.
+
+Suite: 2312 → 2336.
+
 ## What's New in v2.70.0
 
 Headless (`-nogui`) Resolve, measured rather than assumed — and the finding

package/README.md

@@ -1,6 +1,6 @@
 # DaVinci Resolve MCP Server
 
-[![Version](https://img.shields.io/badge/version-2.70.0-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.70.2-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)
@@ -51,15 +51,21 @@ python scripts/install_resolve_bridge.py
 export DAVINCI_RESOLVE_BRIDGE=1      # opt-in; unset changes nothing
 ```
 
-Requires a **framework Python** (python.org). Resolve enumerates `.py` scripts
-only when it finds one — Homebrew, pyenv and conda 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. 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, HMAC-signed requests, one-use
-nonces.
+On **macOS**, this requires a **framework Python** (python.org). Resolve
+enumerates `.py` scripts only when it finds one — Homebrew, pyenv and conda
+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. 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.
+
+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,
+HMAC-signed requests, one-use nonces.
 
 ## Local Control Panel
 

package/docs/SKILL.md

@@ -27,11 +27,20 @@ loopback listener. Install with `python scripts/install_resolve_bridge.py`, star
 it from that menu, and set `DAVINCI_RESOLVE_BRIDGE=1`. Existing tool call sites
 work unchanged. Two things to know when diagnosing it:
 
-- Resolve lists `.py` scripts only when it can find a **framework Python**
-  (python.org). Homebrew/pyenv/conda are not detected and the script simply never
-  appears, with no error. The installer preflights this and ships a Lua canary,
-  which always lists, so "Python not detected" is distinguishable from "wrong
-  folder".
+- On macOS, Resolve lists `.py` scripts only when it can find a **framework
+  Python** (python.org). Homebrew/pyenv/conda are not detected and the script
+  simply never appears, with no error. The installer preflights this and ships a
+  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.
+- 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.0"
+VERSION = "2.70.2"
 # 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.0",
+  "version": "2.70.2",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/scripts/doctor.py

@@ -48,26 +48,96 @@ if not PYTHON.exists():
 SERVER = REPO / "src" / "server.py"
 CODEX_HOME = Path(os.environ.get("CODEX_HOME", "~/.codex")).expanduser()
 CODEX_CONFIG = CODEX_HOME / "config.toml"
+#: Where Resolve installs itself, per platform. Mirrors install.py's
+#: RESOLVE_PATHS — kept in step by tests/test_doctor_paths.py, because these
+#: being macOS-only is exactly the bug that made doctor useless off macOS.
+#:
+#: doctor used to hardcode the Darwin values. Run standalone on Windows (i.e.
+#: without the env vars the npm/install.py flow injects) it then reported four
+#: FAILs naming a `.app` bundle and `fusionscript.so` on a machine that had
+#: neither — while install.py detected the very same install correctly, which is
+#: what made it so confusing to diagnose (issue #106). Linux had the same bug.
+_RESOLVE_PATH_CANDIDATES: dict[str, dict[str, tuple[str, ...]]] = {
+    "darwin": {
+        "app": ("/Applications/DaVinci Resolve/DaVinci Resolve.app",),
+        "api": ("/Library/Application Support/Blackmagic Design/DaVinci Resolve/Developer/Scripting",),
+        "lib": ("/Applications/DaVinci Resolve/DaVinci Resolve.app/Contents/Libraries/Fusion/fusionscript.so",),
+    },
+    "win32": {
+        "app": (r"C:\Program Files\Blackmagic Design\DaVinci Resolve\Resolve.exe",),
+        "api": (
+            r"C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting",
+            r"C:\Program Files\Blackmagic Design\DaVinci Resolve\Developer\Scripting",
+        ),
+        "lib": (r"C:\Program Files\Blackmagic Design\DaVinci Resolve\fusionscript.dll",),
+    },
+    "linux": {
+        "app": ("/opt/resolve/bin/resolve",),
+        "api": (
+            "/opt/resolve/Developer/Scripting",
+            "/opt/resolve/libs/Fusion/Developer/Scripting",
+        ),
+        "lib": (
+            "/opt/resolve/libs/Fusion/fusionscript.so",
+            "/opt/resolve/bin/fusionscript.so",
+        ),
+    },
+}
+
+
+def _platform_key(platform: str | None = None) -> str:
+    """Which candidate set applies. Unknown platforms fall back to Linux."""
+    platform = platform if platform is not None else sys.platform
+    if platform == "darwin":
+        return "darwin"
+    if platform == "win32":
+        return "win32"
+    return "linux"
+
+
+def _resolve_default(kind: str, platform: str | None = None) -> str:
+    """First candidate of `kind` that exists, else the first (so the FAIL line
+    names the canonical location rather than an arbitrary miss)."""
+    candidates = _RESOLVE_PATH_CANDIDATES[_platform_key(platform)][kind]
+    for candidate in candidates:
+        if Path(candidate).exists():
+            return candidate
+    return candidates[0]
+
+
+def _default_claude_config() -> Path:
+    """Claude Desktop's config path, MSIX-aware on Windows (issue #93).
+
+    Claude Desktop for Windows ships as an MSIX package whose %APPDATA% writes
+    are virtualized into a per-package container, so the documented
+    %APPDATA%\\Claude path is a decoy the app never reads. Mirrors
+    install.py's windows_claude_desktop_config().
+    """
+    if sys.platform == "win32":
+        local = Path(os.environ.get("LOCALAPPDATA", Path.home() / "AppData/Local"))
+        try:
+            packages = sorted((local / "Packages").glob("Claude_*"))
+        except OSError:
+            packages = []
+        for pkg in packages:
+            virtual = pkg / "LocalCache" / "Roaming" / "Claude"
+            if virtual.is_dir():
+                return virtual / "claude_desktop_config.json"
+        appdata = Path(os.environ.get("APPDATA", Path.home() / "AppData/Roaming"))
+        return appdata / "Claude" / "claude_desktop_config.json"
+    if sys.platform == "darwin":
+        return Path("~/Library/Application Support/Claude/claude_desktop_config.json").expanduser()
+    xdg = Path(os.environ.get("XDG_CONFIG_HOME", Path.home() / ".config"))
+    return xdg / "Claude" / "claude_desktop_config.json"
+
+
 CLAUDE_CONFIG = Path(
-    os.environ.get(
-        "CLAUDE_DESKTOP_CONFIG",
-        "~/Library/Application Support/Claude/claude_desktop_config.json",
-    )
+    os.environ.get("CLAUDE_DESKTOP_CONFIG", _default_claude_config())
 ).expanduser()
-RESOLVE_APP = Path(os.environ.get("RESOLVE_APP", "/Applications/DaVinci Resolve/DaVinci Resolve.app"))
-RESOLVE_API = Path(
-    os.environ.get(
-        "RESOLVE_SCRIPT_API",
-        "/Library/Application Support/Blackmagic Design/DaVinci Resolve/Developer/Scripting",
-    )
-)
+RESOLVE_APP = Path(os.environ.get("RESOLVE_APP", _resolve_default("app")))
+RESOLVE_API = Path(os.environ.get("RESOLVE_SCRIPT_API", _resolve_default("api")))
 RESOLVE_MODULES = Path(os.environ.get("RESOLVE_SCRIPT_MODULES", RESOLVE_API / "Modules"))
-RESOLVE_LIB = Path(
-    os.environ.get(
-        "RESOLVE_SCRIPT_LIB",
-        "/Applications/DaVinci Resolve/DaVinci Resolve.app/Contents/Libraries/Fusion/fusionscript.so",
-    )
-)
+RESOLVE_LIB = Path(os.environ.get("RESOLVE_SCRIPT_LIB", _resolve_default("lib")))
 
 
 def run(cmd: list[str], timeout: int = 12) -> dict[str, Any]:

package/scripts/install_resolve_bridge.py

@@ -3,9 +3,9 @@
     python scripts/install_resolve_bridge.py --probe-only    # settle the host model first
     python scripts/install_resolve_bridge.py                 # probe + bridge launcher
 
-Deploys to every applicable macOS/Linux location, including the sandboxed App
-Store container used by the free edition — which is why the free edition can be
-installed alongside a direct-download Studio without either disturbing the other.
+Deploys to every applicable macOS/Windows/Linux location, including the sandboxed
+App Store container used by the free edition — which is why the free edition can
+be installed alongside a direct-download Studio without either disturbing the other.
 
 Nothing is started here. Resolve must be restarted after installing so it
 re-scans the Scripts folders, and the script is then run from
@@ -76,6 +76,56 @@ _SANDBOX_FALLBACK_SUFFIX = "Library/Application Support/Fusion/Scripts/Utility"
 #: Containers that are not Resolve (RAW Player, Speed Test, the IO XPC helper).
 _NON_RESOLVE_CONTAINERS = ("BlackmagicRaw", "IOXPC")
 
+#: Windows Scripts/Utility trees, per Blackmagic's own README
+#: (docs/reference/resolve_scripting_api.txt, "Specific user"/"All users").
+#: Two traps, both live in those two lines:
+#:
+#: 1. The per-user tree carries a `Support` segment that the all-users tree does
+#:    NOT. They are not one layout under two roots, and deriving one from the
+#:    other lands in a folder Resolve never scans.
+#: 2. The README writes the per-user root as `%APPDATA%\Roaming\...`, which is
+#:    wrong — `%APPDATA%` already IS `...\AppData\Roaming`, so following it
+#:    literally yields `AppData\Roaming\Roaming\...`. The paths below drop the
+#:    doubled segment; both were confirmed present and writable on the Windows 11
+#:    machine in issue #106.
+_WINDOWS_USER_SCRIPTS_SUFFIX = (
+    "Blackmagic Design/DaVinci Resolve/Support/Fusion/Scripts/Utility"
+)
+_WINDOWS_ALL_USERS_SCRIPTS_SUFFIX = "Blackmagic Design/DaVinci Resolve/Fusion/Scripts/Utility"
+
+
+#: The product folder both Windows trees hang off. Its existence is the "Resolve
+#: is installed" signal — see `_windows_script_candidates`.
+_WINDOWS_PRODUCT_ROOT = "Blackmagic Design/DaVinci Resolve"
+
+
+def _windows_script_candidates() -> list[Path]:
+    """Scripts/Utility trees Resolve scans on Windows (issue #106).
+
+    Gated on the *product* folder, not the Scripts/Utility tree, for the same
+    reason the sandbox branch is: Resolve does not create its `Fusion/Scripts`
+    tree until a script is installed, so requiring the target to pre-exist skips
+    a fresh free-edition install — the one build the bridge exists for. The
+    product folder is created on first launch, so it answers "is Resolve
+    installed" without demanding a folder only we will ever create.
+
+    Per-user first: it is the one a non-elevated account can actually write,
+    while `%PROGRAMDATA%` typically needs an elevated prompt. Ordering it first
+    means the target that will succeed is also the one reported first.
+    """
+    candidates: list[Path] = []
+    for env_var, suffix in (
+        ("APPDATA", _WINDOWS_USER_SCRIPTS_SUFFIX),
+        ("PROGRAMDATA", _WINDOWS_ALL_USERS_SCRIPTS_SUFFIX),
+    ):
+        root = os.environ.get(env_var)
+        if not root:
+            continue
+        target = Path(root) / suffix
+        if target.is_dir() or (Path(root) / _WINDOWS_PRODUCT_ROOT).is_dir():
+            candidates.append(target)
+    return candidates
+
 
 def _is_resolve_container(path: Path) -> bool:
     if not path.name.startswith(_SANDBOX_MARKER):
@@ -91,28 +141,40 @@ def script_targets() -> list[Path]:
     coexist with a direct-download Studio install. Each container contributes
     TWO targets (see the module comment on issue #104): the documented tree
     first, then the Fusion standalone tree that Lite also scans.
+
+    Windows has no sandbox and no `~/Library`, so it gets its own candidate list
+    (issue #106) — without one this returned empty on every Windows machine and
+    the installer exited with "Is Resolve installed?" on a working install.
+    Those candidates arrive pre-vetted, like the sandboxed ones: they are gated
+    on Resolve's product folder rather than on the Scripts tree, which Resolve
+    does not create until a script is installed.
     """
     home = Path.home()
-    candidates = [
-        home / _SCRIPTS_SUFFIX,
-        Path("/") / _SCRIPTS_SUFFIX,
-        home / ".local/share/DaVinciResolve/Fusion/Scripts/Utility",
-    ]
-    containers = home / "Library/Containers"
-    sandboxed: list[Path] = []
-    if containers.is_dir():
-        for entry in sorted(containers.iterdir()):
-            if _is_resolve_container(entry) and (entry / "Data").is_dir():
-                sandboxed.append(entry / "Data" / _SCRIPTS_SUFFIX)
-                sandboxed.append(entry / "Data" / _SANDBOX_FALLBACK_SUFFIX)
+    # Pre-vetted targets, whose tree gets created rather than being required.
+    vetted: list[Path] = []
+    candidates: list[Path] = []
+    if sys.platform == "win32":
+        vetted.extend(_windows_script_candidates())
+    else:
+        candidates = [
+            home / _SCRIPTS_SUFFIX,
+            Path("/") / _SCRIPTS_SUFFIX,
+            home / ".local/share/DaVinciResolve/Fusion/Scripts/Utility",
+        ]
+        containers = home / "Library/Containers"
+        if containers.is_dir():
+            for entry in sorted(containers.iterdir()):
+                if _is_resolve_container(entry) and (entry / "Data").is_dir():
+                    # The container's existence is the signal; the tree gets created.
+                    vetted.append(entry / "Data" / _SCRIPTS_SUFFIX)
+                    vetted.append(entry / "Data" / _SANDBOX_FALLBACK_SUFFIX)
 
     usable: list[Path] = []
     for path in candidates:
         # Non-sandboxed: the install created the tree, so require it.
         if path.is_dir() or (path.parent.is_dir() and os.access(path.parent, os.W_OK)):
             usable.append(path)
-    # Sandboxed: the container's existence is the signal; the tree gets created.
-    usable.extend(sandboxed)
+    usable.extend(vetted)
     return list(dict.fromkeys(usable))
 
 
@@ -197,7 +259,23 @@ def framework_pythons() -> list[str]:
 
 
 def python_preflight() -> dict:
-    """Will Resolve list the Python probe we are about to install?"""
+    """Will Resolve list the Python probe we are about to install?
+
+    The framework-Python trap is **macOS-only**: `/Library/Frameworks/...` does
+    not exist on Windows or Linux, where Resolve finds Python by other means (the
+    registry, or the system interpreter). Running the macOS check there always
+    found nothing and emitted the macOS remediation — telling the Windows 11 user
+    in issue #106, who had a working python.org 3.12, to go install the Python
+    they already had. Report "no known reason it will not list" off macOS rather
+    than a false alarm; the Lua canary still ships either way, so a genuine
+    enumeration problem remains diagnosable.
+    """
+    if sys.platform != "darwin":
+        return {
+            "framework_pythons": [],
+            "resolve_will_list_python_scripts": True,
+            "advice": None,
+        }
     frameworks = framework_pythons()
     return {
         "framework_pythons": frameworks,
@@ -256,48 +334,41 @@ def install(*, probe_only: bool, port: int, rotate: bool) -> dict:
             "No writable DaVinci Resolve Scripts/Utility folder found. Is Resolve installed?"
         )
     installed: list[str] = []
+    # A target can be real, scanned by Resolve, and still unwritable — the
+    # Windows all-users tree under %PROGRAMDATA% needs elevation, and Windows
+    # `os.access(W_OK)` reports the read-only flag rather than the ACL, so the
+    # filter above cannot screen it out. One un-writable target must not abort an
+    # install that already succeeded into the per-user tree, so failures are
+    # collected and only a clean sweep is fatal.
+    skipped: list[tuple[str, str]] = []
     for target in targets:
-        target.mkdir(mode=0o700, parents=True, exist_ok=True)
-        for probe in ("resolve_bridge_probe.py", "resolve_capability_probe.py"):
-            shutil.copy2(REPO / "scripts" / probe, target / probe)
-            installed.append(str(target / probe))
-        # Lua always enumerates; Python only with a framework install. The canary
-        # makes "Python not detected" distinguishable from "wrong folder".
-        canary = target / "resolve_bridge_canary.lua"
-        canary.write_text(_LUA_CANARY, encoding="utf-8")
-        installed.append(str(canary))
-        if not probe_only:
-            runtime = target.parents[1] / ".davinci_mcp_runtime"
-            runtime.mkdir(mode=0o700, parents=True, exist_ok=True)
-            for module in ("resolve_bridge.py", "resolve_bridge_ops.py"):
-                shutil.copy2(REPO / "src/utils" / module, runtime / module)
-                installed.append(str(runtime / module))
-            # A sandboxed (App Store) build cannot read ~/.config at all — inside
-            # the container `~` IS the container, so an absolute real-home path is
-            # unreachable by construction (measured: "Operation not permitted").
-            # The runtime dir is already inside the container, so the config goes
-            # beside the modules. Same token, so the out-of-sandbox client still
-            # authenticates against ~/.config.
-            runtime_config = runtime / "bridge.json"
-            shutil.copy2(CONFIG_PATH, runtime_config)
-            os.chmod(runtime_config, 0o600)
-            installed.append(str(runtime_config))
-            # The launcher IS the menu entry. Without it the modules sit in the
-            # runtime dir with nothing able to start them.
-            launcher_source = (REPO / "scripts/resolve_bridge_launcher.py").read_text(encoding="utf-8")
-            launcher = launcher_source.replace(
-                "@@RUNTIME_ROOT_B64@@",
-                base64.urlsafe_b64encode(str(runtime).encode("utf-8")).decode("ascii"),
-            ).replace(
-                "@@CONFIG_PATH_B64@@",
-                base64.urlsafe_b64encode(str(CONFIG_PATH).encode("utf-8")).decode("ascii"),
-            )
-            launcher_path = target / "resolve_bridge.py"
-            launcher_path.write_text(launcher, encoding="utf-8")
-            installed.append(str(launcher_path))
+        try:
+            target.mkdir(mode=0o700, parents=True, exist_ok=True)
+            _install_to(target, probe_only=probe_only, installed=installed)
+        except OSError as exc:
+            skipped.append((str(target), str(exc)))
+    if not installed:
+        raise SystemExit(
+            "Found DaVinci Resolve Scripts/Utility folders but could not write to "
+            "any of them:\n"
+            + "\n".join(f"  {path}: {reason}" for path, reason in skipped)
+            + "\nRe-run from an account that can write these folders (on Windows, "
+            "the %PROGRAMDATA% tree needs an elevated prompt; the per-user "
+            "%APPDATA% tree does not)."
+        )
     result = {"installed": installed, "probe_only": probe_only, "python": python_preflight()}
     stale = stale_container_warning(targets)
     result["warnings"] = [stale] if stale else []
+    if skipped:
+        result["warnings"].append(
+            "Skipped "
+            + str(len(skipped))
+            + " unwritable Scripts/Utility folder(s): "
+            + "; ".join(f"{path} ({reason})" for path, reason in skipped)
+            + ". This is harmless as long as the bridge appears under "
+            "Workspace > Scripts."
+        )
+    result["skipped"] = [path for path, _ in skipped]
     if not probe_only:
         loaded = json.loads(CONFIG_PATH.read_text(encoding="utf-8"))
         result["config"] = {"path": str(CONFIG_PATH),
@@ -305,6 +376,53 @@ def install(*, probe_only: bool, port: int, rotate: bool) -> dict:
     return result
 
 
+def _install_to(target: Path, *, probe_only: bool, installed: list[str]) -> None:
+    """Place the probes, canary and (unless probe-only) the bridge into `target`.
+
+    Raises OSError if the target turns out to be unwritable; `install()` treats
+    that as a skip rather than a failure so one un-writable tree cannot abort an
+    install that succeeded elsewhere.
+    """
+    for probe in ("resolve_bridge_probe.py", "resolve_capability_probe.py"):
+        shutil.copy2(REPO / "scripts" / probe, target / probe)
+        installed.append(str(target / probe))
+    # Lua always enumerates; Python only with a framework install. The canary
+    # makes "Python not detected" distinguishable from "wrong folder".
+    canary = target / "resolve_bridge_canary.lua"
+    canary.write_text(_LUA_CANARY, encoding="utf-8")
+    installed.append(str(canary))
+    if probe_only:
+        return
+    runtime = target.parents[1] / ".davinci_mcp_runtime"
+    runtime.mkdir(mode=0o700, parents=True, exist_ok=True)
+    for module in ("resolve_bridge.py", "resolve_bridge_ops.py"):
+        shutil.copy2(REPO / "src/utils" / module, runtime / module)
+        installed.append(str(runtime / module))
+    # A sandboxed (App Store) build cannot read ~/.config at all — inside
+    # the container `~` IS the container, so an absolute real-home path is
+    # unreachable by construction (measured: "Operation not permitted").
+    # The runtime dir is already inside the container, so the config goes
+    # beside the modules. Same token, so the out-of-sandbox client still
+    # authenticates against ~/.config.
+    runtime_config = runtime / "bridge.json"
+    shutil.copy2(CONFIG_PATH, runtime_config)
+    os.chmod(runtime_config, 0o600)
+    installed.append(str(runtime_config))
+    # The launcher IS the menu entry. Without it the modules sit in the
+    # runtime dir with nothing able to start them.
+    launcher_source = (REPO / "scripts/resolve_bridge_launcher.py").read_text(encoding="utf-8")
+    launcher = launcher_source.replace(
+        "@@RUNTIME_ROOT_B64@@",
+        base64.urlsafe_b64encode(str(runtime).encode("utf-8")).decode("ascii"),
+    ).replace(
+        "@@CONFIG_PATH_B64@@",
+        base64.urlsafe_b64encode(str(CONFIG_PATH).encode("utf-8")).decode("ascii"),
+    )
+    launcher_path = target / "resolve_bridge.py"
+    launcher_path.write_text(launcher, encoding="utf-8")
+    installed.append(str(launcher_path))
+
+
 def main() -> int:
     parser = argparse.ArgumentParser(description=__doc__)
     parser.add_argument("--probe-only", action="store_true",

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.0"
+VERSION = "2.70.2"
 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.0"
+VERSION = "2.70.2"
 
 import base64
 import os