davinci-resolve-mcp 2.224.3 → 3.0.1

package/CHANGELOG.md

@@ -2,6 +2,203 @@
 
 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 v3.0.1 — project deletion is gated, and the open project is refused by default
+
+A security fix, published as [GHSA-gmp7-qjp9-m7gm](https://github.com/samuelgursky/davinci-resolve-mcp/security/advisories/GHSA-gmp7-qjp9-m7gm).
+One behaviour change existing callers may notice is called out below.
+
+### Security
+
+- **`project_manager delete` permanently deleted any named project — including
+  the one open in Resolve — without confirmation, and no gate saw it.** It runs
+  through `delete_project_safely`, a *reliability* helper that works around
+  DeleteProject's flakiness and session lock by closing the open project and
+  then deleting it. The `project_manager` tool carried no `@_destructive_op`,
+  `delete` was not registered, and the CRITICAL risk rule written for project
+  deletion named `delete_project`, an action no tool dispatches. So it matched
+  nothing: safe mode, dry-run refusal and the security audit log never saw a
+  project deletion.
+- **Thirteen further deletes that the classifier already rated HIGH were not
+  enforced, for the same reason.** They are the three `render` deletes,
+  `render_presets.delete_burnin`, `gallery_stills.delete_stills`, `fusion_comp`
+  `delete_tool` and `delete_keyframe`, `timeline_item.delete_keyframe`, the three
+  `media_pool_item_markers` deletes, `project_settings.delete_color_group` and
+  `resolve_control.delete_user_preferences_preset`. Safe mode is enforced only
+  by the decorator, and only for registered actions, so these ratings were a
+  promise nothing kept.
+
+### Changed
+
+- **The raw `delete` now refuses the currently open project unless
+  `close_current=True`**, matching `safe_project_delete`. This is the one change
+  existing callers may notice: a call that used to close and delete the open
+  project now returns an error, until it passes `close_current=True`.
+- All of the actions above are registered and their tools decorated. The project
+  delete is CRITICAL, and `safe_project_delete` and the thirteen others are HIGH,
+  so all are blocked while safe mode is on. An explicit dry run is refused
+  unless the action honours it natively; only `safe_project_delete` does, and
+  keeps working. Every call is audited. None of them archives the timeline,
+  except the keyframe deletes on `fusion_comp` and `timeline_item`, which change
+  timeline items and so still do.
+- **`remove_motion_blur`** (on `folder` and `media_pool_item`) is **re-rated
+  MEDIUM**. It renders new media and never touches the source, and was already
+  confirm-gated for exactly that reason, but the `remove_` name-prefix rule had
+  rated it HIGH on its name alone. It is now audited, and not blocked by safe
+  mode.
+- **The name-prefix rule is now a fallback for unlisted actions**: an explicit
+  lower rating wins. Before, it fired ahead of the LOW and MEDIUM tables and
+  could not be overridden. No existing rating changed except `remove_motion_blur`
+  — no LOW, MEDIUM or graph-LUT entry started with `delete_` or `remove_`.
+
+### Fixed
+
+- **Nine risk rules named actions that no tool dispatches, and so protected
+  nothing.** On `project_manager`: `delete_project`, now repointed at the real
+  `delete`, plus `close_project_without_saving` and `save_project_as`. On
+  `edit_engine`: `auto_cut_silence` and `ripple_trim`. On `timeline`: `cut_clip`,
+  `delete_clip_by_id`, `delete_markers` and `ripple_delete` — which is a CutList
+  entry kind inside `apply_cuts`, not an action. The rest were removed; since
+  they never matched, removing them changes nothing at runtime. An existing test
+  even asserted that the dead `delete_project` rule classified as CRITICAL — true
+  of a name no tool uses, and part of how it survived. It now tests the real
+  `delete`.
+- **The bridge installer's Lua canary gave only the pre-21.1 diagnosis** — that
+  Resolve cannot find a Python 3. On free 21.1 that is wrong, because Python
+  scripting moved to Studio (#203). Its comments and printed output now give both
+  causes, the newer first (#219). The printed post-install guidance was already
+  corrected in v2.224.1.
+
+### Added
+
+- **`tests/test_write_enforcement_ratchet.py`** fails the suite in three cases:
+  - an action is rated destructive but not enforced;
+  - a risk rule names an action no tool dispatches;
+  - a new write-style action appears with neither a rating nor a registry entry.
+
+  The 144 unrated write-style actions that exist today are frozen as a backlog.
+  Rating one forces its removal from the list, so it can only shrink. This is
+  the second instance of this gap in two days, and the first time it cannot
+  come back unnoticed.
+- `tests/test_project_delete_guard.py` pins the delete guard, its rating and its
+  enforcement.
+
+### Documentation
+
+- Removed a stale tool count from `docs/authoring/script-plugin-authoring.md`.
+
+### Validation
+
+- Full suite green: 3,482 passed, 1 skipped. Every static and drift gate is clean, including
+  the native-dry-run scan. That scan requires the native-dry-run list to match,
+  exactly, the registered actions whose handlers read `dry_run`, which is how
+  `safe_project_delete` was confirmed as the only one.
+- No live Resolve run. The gating is decorator-level and verified offline. The
+  delete guard is tested against a fake project manager, deliberately:
+  exercising it live means deleting a real project.
+
+## What's New in v3.0.0 — the server no longer executes caller-supplied code, and every plugin write is gated
+
+**A breaking release.** Two public actions are removed. The rest of the change
+is a security fix, published as [GHSA-vh75-g46q-hgcw](https://github.com/samuelgursky/davinci-resolve-mcp/security/advisories/GHSA-vh75-g46q-hgcw).
+
+### Removed (breaking)
+
+- **`script_plugin run_inline`** ran a caller's source directly. Python ran as a
+  subprocess on the host, with the user's privileges and a live Resolve handle.
+  Lua ran inside Resolve's Fusion engine with `os` and `io` in scope, so
+  `os.execute` reached the shell.
+- **`script_plugin execute`** ran an installed script. `install` accepts
+  caller-supplied source, so the two together did the same thing in two steps.
+- **`probe_script_lifecycle`'s `execute` option.** The probe now **refuses**
+  `execute=true` up front, before generating or installing anything. Skipping it
+  silently would have reported a probe as complete for a step it never ran.
+
+Both actions shipped in v2.5.0 as documented features, and the agent guidance
+recommended `run_inline` for conversational queries. They are removed under the
+maintainer's policy that this server does not execute caller-supplied code, in
+any form. Calling either now returns an error that names the removal and points
+to the replacement, rather than a bare "unknown action".
+
+### Migration
+
+- Install the script with `script_plugin install`, then run it yourself from
+  **Workspace → Scripts** inside Resolve. Python output appears in Resolve's
+  Console.
+- For queries and edits in conversation, use the typed tools.
+
+### Security
+
+- **Plugin-folder writes passed every gate as reads.** `install` and `remove`
+  on `dctl`, `fuse_plugin` and `script_plugin`, plus `safe_install_extension`
+  and `safe_remove_extension`, were in neither write table. The risk classifier
+  returned `recognised=False` — a bare `remove` misses the `remove_*` prefix
+  rule — the destructive registry had no entry, and `fuse_plugin` and
+  `script_plugin` carried no `@_destructive_op` at all. So safe mode, dry-run
+  refusal and the security audit log treated them as reads. These are the
+  actions that put files into folders Resolve and Fusion later load and run: a
+  Fuse registers on the next restart, a script runs when clicked.
+- **`run_inline` and `execute` were in the same state.** With safe mode on, the
+  setting whose whole purpose is to block dangerous operations let arbitrary
+  code execution through as a read.
+- All of this is fixed here, for every version from v2.5.0 onward, and published
+  as the advisory linked above. A read-only audit confirmed `script_plugin` was
+  the only path in the repository that ran caller-supplied code: the Node
+  advanced server spawns fixed binaries only, never with `shell: true`.
+
+### Fixed
+
+- **A dry run of `install` or `remove` wrote or deleted the file for real.**
+  Dry-run refusal only applies to registered actions, so `dry_run=true` was
+  silently ignored. It is now refused with `DRY_RUN_UNAVAILABLE`. For a genuine
+  preview, use `safe_install_extension` / `safe_remove_extension`, which honour
+  `dry_run` themselves.
+- **The lifecycle probes skipped the gate.** They called the raw `_safe_*`
+  helpers directly, and `safe_remove_extension` unlinks the file itself, so
+  their installs and cleanup deletes reached disk ungated. They now go through
+  `script_plugin(...)`, and an AST guard keeps it that way.
+- **Plugin writes would have snapshotted the open timeline.** Once registered,
+  every write falls into version-on-mutate archiving — and `dctl encrypt_native`,
+  registered in v2.224.0, already archived a timeline version on every call. A
+  new non-timeline exemption keeps these writes gated and audited but skips the
+  archive. It also never resolves the versioning context, which reaches Resolve:
+  installing a shader must neither touch the project nor launch Resolve.
+
+### Changed — risk ratings
+
+- `install` and `safe_install_extension`: **MEDIUM** — audited and dry-run-honest,
+  not blocked by safe mode, like the other create-style writes.
+- `remove` and `safe_remove_extension`: **HIGH** — blocked while safe mode is on.
+  `allow_risky_operation: true` overrides a single call.
+- Safe mode is off by default, and `confirmation_required` is informational, not
+  a token demand. So for most users the visible change is that these calls are
+  now audited, and a dry run means a dry run.
+
+### Documentation
+
+- `docs/SKILL.md`, `docs/authoring/script-plugin-authoring.md` (retitled; its
+  execution section replaced by how to run an installed script) and the
+  extension-authoring kernel map describe the gated, execution-free surface.
+  So does the agent-facing prompt guidance, which had told agents to prefer
+  `run_inline` for inspecting Resolve state.
+- Two measured facts about Resolve's Lua bridge, found while building the
+  removed `run_inline`, are kept as reference because they describe Resolve
+  itself: `fusion.Execute()` is a no-op from the Python bridge in 20.x, and
+  `fusion.RunScript()` returns before the script finishes.
+
+### Validation
+
+- Full suite green: 3,472 passed, 1 skipped. The drop from the previous run is
+  exactly the deleted execution tests, less the five new policy tests.
+- New tests pin both halves: every plugin write is a rated, recognised write; a
+  dry run on the real tools is refused rather than executed; the safe-install
+  dry run still works; plugin writes never archive or reach Resolve; safe mode
+  blocks deletes and not installs; the removed actions refuse with a migration
+  pointer; the probe refuses `execute` before any side effect; and an AST scan
+  finds no `RunScript`, `Execute`, `exec` or `eval` call anywhere in `src/`.
+- No live Resolve run. The actions that remain behave as before apart from the
+  gate, which is decorator-level and verified offline. The removed actions can
+  only be verified absent, which the tests do.
+
 ## What's New in v2.224.3 — the Windows import guard covers the advanced server
 
 Contributed by @Dev-next-gen (#222). Test-only; no behaviour changed.

package/README.md

@@ -2,7 +2,7 @@
 
 English | [简体中文](README.zh-CN.md)
 
-[![Version](https://img.shields.io/badge/version-2.224.3-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-3.0.1-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-36%20(377%20full)-blue.svg)](#server-modes)

package/README.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](README.md) | 简体中文
 
-[![Version](https://img.shields.io/badge/version-2.224.3-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-3.0.1-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-36%20(377%20full)-blue.svg)](#服务器模式)
@@ -12,7 +12,7 @@
 [![Python](https://img.shields.io/badge/python-3.10+-green.svg)](https://www.python.org/downloads/)
 [![License](https://img.shields.io/badge/license-MIT-blue.svg)](https://opensource.org/licenses/MIT)
 
-> 本翻译对应 v2.224.3 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
+> 本翻译对应 v3.0.1 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
 
 一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
 

package/docs/SKILL.md

@@ -118,39 +118,47 @@ directories. They are *authoring* tools — every other tool in this server wrap
 Resolve's scripting API, while these three emit and install plugin/script
 source. Status: lifecycle-verified in DaVinci Resolve Studio 20.3.2.9 for
 MCP-marked install/read/list/remove, regular DCTL `refresh_luts`, ACES/Fuse
-restart-required classification, Python installed-script execution, and
-Python/Lua `run_inline`. Use `docs/kernels/extension-authoring-kernel.md` for the
+restart-required classification. Script execution — `execute` and `run_inline` —
+was removed in v3.0.0: this server does not run caller-supplied code. Use
+`docs/kernels/extension-authoring-kernel.md` for the
 kernel boundary map, `docs/authoring/fuse-dctl-authoring.md` for the Fuse + DCTL coverage
 matrix, and `docs/authoring/script-plugin-authoring.md` for the script DSL spec and the
-conversational-execution model. For hand-authoring `.setting` template files
+install paths. For hand-authoring `.setting` template files
 (Edit effects/transitions/titles/generators and Fusion macros) — the format,
 control catalog, thumbnail conventions, install paths, and gotchas, plus copyable
 starter templates — see `docs/authoring/setting-files/`.
 
+**Plugin writes are gated like every other write.** `install` and `remove` on all
+three tools, and `script_plugin`'s `safe_install_extension` / `safe_remove_extension`,
+are registered destructive actions. An explicit `dry_run=true` on `install` or
+`remove` is refused with `DRY_RUN_UNAVAILABLE` rather than executed — for a real
+preview use `safe_install_extension` / `safe_remove_extension`, which honour
+`dry_run` themselves. `remove` is rated HIGH and is blocked while safe mode is on
+(`allow_risky_operation: true` overrides a single call); `install` is MEDIUM.
+Every call is recorded in the security audit log, and none of them archives the
+timeline — they write plugin folders, not the project. The `probe_*_lifecycle`
+actions route their installs and cleanup deletes through the same gate.
+
 Extension Authoring kernel actions (v2.16.0+) are exposed through
 `script_plugin`:
 
 - `extension_capabilities`
 - `probe_fuse_lifecycle(name?, kind?, install?, cleanup?)`
 - `probe_dctl_lifecycle(name?, kind?, category?, install?, refresh_luts?, cleanup?)`
-- `probe_script_lifecycle(name?, language?, category?, install?, execute?, cleanup?)`
+- `probe_script_lifecycle(name?, language?, category?, install?, cleanup?)`
 - `safe_install_extension(extension_type, name, source?|kind?, dry_run?)`
 - `safe_remove_extension(extension_type, name, dry_run?)`
 - `refresh_or_restart_required(extension_type, category?)`
 - `extension_boundary_report(include_template_matrix?)`
 
 Key behavioral notes for `script_plugin`:
-- `run_inline(source, language)` runs ad-hoc Lua/Python in Resolve and returns
-  stdout + result — use this for one-off conversational queries against the
-  Resolve API instead of building+installing a script.
+- **No script execution.** `run_inline` and `execute` were removed in v3.0.0:
+  this server does not run caller-supplied code, in any form. `install` puts a
+  script in Resolve's Workspace › Scripts menu; running it is the user's action
+  inside Resolve. For conversational queries against the Resolve API, use the
+  typed tools rather than a script.
 - `language` accepts `lua`, `py`, or the human-facing aliases `python` and
   `python3`.
-- `execute(name, category, language)` runs an installed script; Python stdout
-  and stderr are captured, while installed Lua execution can return false from
-  the Python bridge even when install/read/list/remove worked.
-- Lua scripts: `fusion.Execute()` from the Python bridge is a no-op in
-  Resolve 20.x — `_run_inline_lua` works around this with `RunScript` against
-  a temp file plus completion-sentinel polling on `app:SetData/GetData`.
 - Fuse install path on macOS is `…/DaVinci Resolve/Fusion/Fuses/` (NOT
   `Support/Fusion/Fuses/` as the SDK doc lists). The MCP path helpers handle
   this; if you're staging files manually, use the path the implementation

package/docs/authoring/script-plugin-authoring.md

@@ -1,10 +1,10 @@
-# Script Plugin Authoring & Conversational Resolve Scripting
+# Script Plugin Authoring
 
-The `script_plugin` compound tool (introduced in v2.5.0) generates, installs,
-and **executes** Resolve-page Lua/Python scripts. It closes the conversational
-loop: an LLM with access to the MCP can describe a workflow, generate the
-script, install it as a Resolve menu item, and execute it — all in one turn —
-with the script's stdout streamed back into the conversation.
+The `script_plugin` compound tool (introduced in v2.5.0) generates, validates
+and installs Resolve-page Lua/Python scripts. **It does not run them.** Script
+execution — `run_inline` and `execute` — was removed in v3.0.0, because this
+server does not execute caller-supplied code. An installed script appears as a
+Resolve menu item, and running it is the user's action, inside Resolve.
 
 Unlike `fuse_plugin` (which authors Fusion image-processing tools) and `dctl`
 (which authors color-page shaders), `script_plugin` targets the
@@ -15,11 +15,11 @@ automation.
 
 | Goal | Use |
 |---|---|
-| One-off conversational query against Resolve | `script_plugin('run_inline', ...)` |
-| Custom workflow you want as a permanent menu item | `script_plugin('install', ...)` then `('execute', ...)` |
+| One-off query or change against Resolve | The typed Resolve API tools — no script, no execution |
+| Custom workflow you want as a permanent menu item | `script_plugin('install', ...)`, then the user runs it from Workspace → Scripts |
 | Image-processing node for the Fusion page | `fuse_plugin` |
 | Color-page programmable transform | `dctl` |
-| Anything the existing 28 wrapped Resolve API tools already cover | The wrapped tool — no scripting needed |
+| Anything the wrapped Resolve API tools already cover | The wrapped tool — no scripting needed |
 
 ## Two template kinds
 
@@ -93,43 +93,24 @@ Real-world example: a script supervisor's CSV with Filename, Scene, Take,
 Camera, Lens columns. Single rule maps each clip to its row and populates
 all metadata fields plus organizes into Scene bins. Six lines of RULES.
 
-## Conversational execution: `run_inline` and `execute`
-
-The two actions that close the loop:
-
-### `run_inline(source, language, timeout?)`
-Run an ad-hoc Lua or Python snippet inside Resolve, get stdout + return
-value back. No file persistence.
-
-**Python**: writes source to a temp file with `resolve`/`project`/`mp`/
-`timeline` pre-bound, runs as subprocess, captures stdout/stderr.
-
-**Lua**: wraps source so `print()` is intercepted into a buffer, runs via
-`fusion.RunScript()`, polls a completion sentinel, reads stdout + return
-value back via `app:SetData()`/`fusion.GetData()`. (Note: `fusion.Execute()`
-from the Python bridge is a no-op in Resolve 20.x — `RunScript()` against a
-file is the only working path. The implementation handles this.)
-
-Example:
-```python
-script_plugin('run_inline', {
-    'source': '''
-print(f"Project: {project.GetName()}")
-print(f"Bins: {len(mp.GetRootFolder().GetSubFolderList() or [])}")
-''',
-    'language': 'py',
-})
-# → {success: True, stdout: "Project: My Show\nBins: 12\n", exit_code: 0}
-```
+## Running an installed script
+
+`script_plugin` installs scripts; it does not run them. v3.0.0 removed the two
+actions that did:
+
+- `run_inline` ran a caller's source directly — Python as a subprocess on the
+  host, with a live Resolve handle, or Lua inside Resolve's Fusion engine with
+  `os` and `io` in scope.
+- `execute` ran an installed script, which `install` could have just written
+  from caller-supplied source.
 
-### `execute(name, category, language, args?, timeout?)`
-Run an installed script. Same return shape as `run_inline`.
+Neither passed any of the server's safety gates, and the maintainer policy is
+that the server never executes caller-supplied code. Calling either now returns
+an error that says so and points here.
 
-**Python**: subprocess captures full stdout/stderr.
-**Lua**: `fusion.RunScript()`; print() output goes to Resolve Console
-(can't capture). For Lua scripts that need to return data, have them write
-to `app:SetData()` and the caller reads via the existing `fusion_comp`
-tooling.
+After `install`, the user runs the script from **Workspace → Scripts →
+\<category\>** inside Resolve; Python output appears in Resolve's Console. For
+queries and edits in conversation, use the typed tools.
 
 ## Install paths
 
@@ -158,32 +139,19 @@ familiar for data-heavy workflows. The same RULES table syntax works in both
 Verified on DaVinci Resolve Studio 20.3.2.9, macOS:
 
 - ✅ Scripts appear in Workspace → Scripts → \<category\> after install (no restart needed)
-- ⚠️ Installed Lua script execution via `fusion.RunScript(path)` can return
-  `False` from the Python bridge even when install/read/list/remove work. Use
-  `run_inline(language="lua")` when captured output or return values matter.
-- ✅ Python scripts execute via subprocess with full stdout/stderr capture
-- ✅ `run_inline` Lua: stdout captured (with tabs), return value captured, errors trapped with line numbers
-- ✅ `run_inline` Python: full Resolve API access, project + media-pool + timeline pre-bound
 - ✅ Both engines (Lua and Python) compile without errors
 - ✅ DSL coverage tests confirm every documented source/action/target/transform/strategy is present in both engines
 
-## Implementation notes (for maintainers)
-
-Two non-obvious behaviors of Resolve's Lua bridge surfaced during live
-testing and are encoded in the implementation:
-
-1. **`fusion.Execute(luaSource)` is a no-op** when called from the Python
-   `DaVinciResolveScript` bridge in Resolve 20.x. It returns `None` and has
-   no observable side effects. Don't use it. Use `fusion.RunScript(filepath)`
-   against a temp file instead.
+## Resolve's Lua bridge — reference
 
-2. **`fusion.RunScript()` is asynchronous.** It returns before the script
-   finishes. Reading `fusion.GetData()` immediately gives stale values. The
-   implementation polls a completion-sentinel slot (`__mcp_done__`) until
-   the wrapped Lua sets it to `"1"`, then reads results.
+Two measured facts about Resolve itself, found while building the now-removed
+`run_inline`, stay true of Resolve and are kept here for reference:
 
-These constraints are unique to the Lua side; Python's subprocess approach
-is straightforwardly synchronous.
+1. **`fusion.Execute(luaSource)` is a no-op** from the Python
+   `DaVinciResolveScript` bridge in Resolve 20.x: it returns `None` with no
+   observable side effects.
+2. **`fusion.RunScript(filepath)` is asynchronous**: it returns before the
+   script finishes, so an immediate `fusion.GetData()` reads stale values.
 
 ## Source media integrity
 

package/docs/kernels/extension-authoring-kernel.md

@@ -33,7 +33,7 @@ All kernel actions are exposed through `script_plugin`.
 | `extension_capabilities` | Report Fuse, DCTL, script paths, template kinds, MCP markers, lifecycle rules, and safety guards. |
 | `probe_fuse_lifecycle` | Generate, validate, optionally install/read/list/remove a Fuse template. |
 | `probe_dctl_lifecycle` | Generate, validate, optionally install/read/list/remove a LUT or ACES DCTL template. |
-| `probe_script_lifecycle` | Generate, validate, optionally install/read/list/execute/remove a Resolve-page script. |
+| `probe_script_lifecycle` | Generate, validate, optionally install/read/list/remove a Resolve-page script. Refuses `execute` (removed in v3.0.0). |
 | `safe_install_extension` | Install Fuse, DCTL, or script source/templates with `_mcp_` name and marker guards. |
 | `safe_remove_extension` | Remove Fuse, DCTL, or script files only when the file is MCP-marked by default. |
 | `refresh_or_restart_required` | Classify whether an extension needs LUT refresh, menu refresh, UI reload, or Resolve restart. |
@@ -47,8 +47,6 @@ All kernel actions are exposed through `script_plugin`.
 | Regular DCTL | LUT directory | `project_settings.refresh_luts` picks it up. | Not required for LUT-category DCTLs. |
 | ACES IDT/ODT DCTL | ACES Transforms IDT/ODT | Not picked up by LUT refresh. | Required. |
 | Resolve-page script | Fusion/Scripts category directory | Workspace Scripts menu refreshes when opened. | Not required. |
-| Inline Python script | Temp file subprocess | Captured synchronously. | Not required. |
-| Inline Lua script | Temp Lua file via `fusion.RunScript` | Captured through Fusion app data bridge. | Not required. |
 
 ## Supported Findings
 
@@ -59,20 +57,17 @@ All kernel actions are exposed through `script_plugin`.
 - ACES IDT DCTL template generation, install into `ACES Transforms/IDT/MCP`,
   read, list, and safe remove worked. It remains restart-required before Resolve
   can use the transform.
-- Python Resolve-page script template generation, install, read, list, execute,
-  stdout/stderr capture, and safe remove worked.
-- `script_plugin.run_inline` worked for Python with stdout capture.
-- `script_plugin.run_inline` worked for Lua with stdout and return-value capture.
+- Python Resolve-page script template generation, install, read, list, and safe
+  remove worked.
 - The template matrix generated and validated every Fuse, DCTL, and script
   template kind.
 - Safe install rejected unmarked provided source by default.
 
 ## Boundaries
 
-- Installed Lua script execution through `fusion.RunScript(path)` returned
-  `success=False` in the release probe, even though install/read/list/remove
-  worked and inline Lua execution worked. Use `run_inline(language="lua")` when
-  captured output/return values matter.
+- **No script execution.** `run_inline` and `execute` were removed in v3.0.0:
+  the server does not execute caller-supplied code, and the probes no longer run
+  scripts. Installed scripts are run by the user from Workspace → Scripts.
 - New Fuses still require a Resolve restart to appear as registered Fusion
   tools. The MCP can install/remove files but cannot force Fusion to register a
   new Fuse in-process.
@@ -93,8 +88,8 @@ python3.11 tests/live_extension_authoring_validation.py --output-dir /tmp/extens
 ```
 
 The harness creates a disposable `_mcp_` project, installs and removes a
-generated Fuse, regular DCTL, ACES DCTL, Python script, and Lua script, probes
-inline Python/Lua execution, writes JSON and Markdown reports, deletes the
+generated Fuse, regular DCTL, ACES DCTL, Python script, and Lua script, writes
+JSON and Markdown reports, deletes the
 project, and removes its temp work directory.
 
 Use `--keep-open` only when you intentionally want to inspect the disposable

package/install.py

@@ -37,7 +37,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "2.224.3"
+VERSION = "3.0.1"
 # 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.224.3",
+  "version": "3.0.1",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/scripts/install_resolve_bridge.py

@@ -288,7 +288,9 @@ _CANARY_NAME = "resolve_bridge_canary.lua"
 
 _LUA_CANARY = """-- Installed by davinci-resolve-mcp as an enumeration canary.
 -- If THIS appears under Workspace > Scripts but resolve_bridge_probe does not,
--- Resolve is listing Lua and silently skipping Python: it cannot find a Python 3.
+-- Resolve is listing Lua and silently skipping Python. On Resolve 21.1+ FREE
+-- that is expected: Python scripting moved to Studio (issue #203), and nothing
+-- below will change it. On Studio, or 21.0.x and earlier, it cannot find a Python 3.
 -- It looks at PYTHON3HOME, then /usr/local/bin/python3 -- and nowhere else, which
 -- is why Homebrew, pyenv, uv and conda interpreters go unseen. Either point it at
 -- the one you have (no sudo, but does NOT survive a reboot):
@@ -299,9 +301,12 @@ _LUA_CANARY = """-- Installed by davinci-resolve-mcp as an enumeration canary.
 -- already looks, which persists:
 --   sudo ln -s "$(command -v python3)" /usr/local/bin/python3
 -- A python.org build creates that symlink for you. Restart Resolve after.
-print("Resolve is enumerating scripts. If the Python probe is missing, Resolve")
-print("cannot find a Python 3: set PYTHON3HOME with launchctl setenv, or install")
-print("a python.org build. Homebrew/pyenv/uv/conda are not looked at directly.")
+print("Resolve is enumerating scripts. If the Python probe is missing:")
+print("- Resolve 21.1+ FREE: Python scripting moved to Studio, so .py scripts")
+print("  no longer list at all (issue #203). No Python setting changes that.")
+print("- Studio, or 21.0.x and earlier: Resolve cannot find a Python 3. Set")
+print("  PYTHON3HOME with launchctl setenv, or install a python.org build.")
+print("  Homebrew/pyenv/uv/conda are not looked at directly.")
 """
 
 

package/src/granular/common.py

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