Security release. Upgrading is recommended for anyone running the MCP server.
Security
Artifact downloads are confined to an approved directory (GHSA-92q4-9x75-55rf)
validate_output_path relied on a denylist of sensitive locations, so any path it did not happen to list stayed writable. A prompt injection carried in notebook source content could steer an MCP client into saving artifact bytes over shell startup files (~/.zshenv, ~/.zprofile), agent instruction files (~/.codex/AGENTS.md, ~/.cursor/skills/*/SKILL.md), git hooks, or launch agents, which other programs then execute or read as instructions.
The MCP download tools (download_artifact, download_all_artifacts) now confine every write to a single download directory, resolve each path before checking it so a symlink cannot hop outside, and write to the path that was actually validated. The denylist stays as a second layer and now covers more locations.
Reported by @Naor-Peretz.
Changed
MCP downloads now default to a fixed directory. A relative path from an MCP client resolves inside the download directory instead of the server's working directory, and an absolute path outside it is refused.
The directory is NOTEBOOKLM_DOWNLOAD_DIR when set, otherwise ~/Downloads/gemini-notebook, falling back to ~/.notebooklm-mcp-cli/downloads/ on systems with no ~/Downloads such as headless Linux hosts, containers, and Windows installs with a relocated Downloads folder.
CLI downloads are unchanged. nlm download ... -o <path> still writes wherever you point it, because there the path comes from the person running the command rather than from a model.
Upgrading
uv cache clean && uv tool install --force notebooklm-mcp-cliRestart your MCP server afterwards. The server holds code in memory, so a reinstall alone does not apply the fix to a running server.
Full changelog: https://github.com/jacob-bd/gemini-notebook-mcp-cli/blob/main/CHANGELOG.md