proton-drive-mcp 1.0.34 → 1.0.35

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## 1.0.35 — 2026-09-03
+
+Continued the live-testing bug sweep. This round found a serious silent-data-corruption bug in `drive_move`, confirmed by a full live reproduction against the real account, plus the same root cause in `drive_copy`. The same fix hardens three more structurally identical code paths (`trash`, `restore`, `delete`) against the same failure mode.
+
+### Fixed
+- **`drive_move` could silently rename the WRONG file and report false success**, when moving across folders into a destination that already has an item with the same name. Root cause confirmed live: `filesystem move` exits **0** with `[{ok:false, error:{name:"NodeWithSameNameExistsValidationError", ...}}]` on a name collision — not a non-zero exit code. `move()`'s cross-folder composition (`move` the item, then `rename` it) discarded this result entirely, assumed the move always succeeded, and blindly renamed *whatever item happened to already exist* at the computed destination path — which, on a collision, was the pre-existing unrelated file, not the one that was supposed to move. Reproduced the full scenario live: source file stayed in its original folder, untouched, while a completely different file in the destination folder got silently renamed, and the tool reported "Moved: ..." success throughout. Now `move()` checks the result and fails cleanly with a clear error instead of proceeding.
+- **`drive_copy` reported false success on the same kind of destination-name collision.** Same root cause, confirmed live the same way (`filesystem copy` also returns `[{ok:false, ...}]` with exit 0) — `copy()` discarded the result and unconditionally reported success. Now checked the same way.
+- **Same defensive check added to `trash`, `restore`, and `delete`**, which share the identical CLI response shape (all support batch operation via `path...` and report per-item `{uid, ok, error}` results) — hardening them against the same silent-failure class even though a live collision wasn't independently reproduced for each.
+
 ## 1.0.34 — 2026-09-03
 
 Continued the live-testing bug sweep from v1.0.33. 7 more real, confirmed bugs across two rounds — every one reproduced live against the real Proton Drive CLI and account before being called a bug, and every fix re-verified live afterward.

package/dist/services/drive.js

@@ -29,6 +29,27 @@ function unwrapResult(value, fallback = "") {
 function escapeNameForPath(name) {
     return name.replace(/\//g, "\\/");
 }
+// filesystem move/copy/trash/restore/delete all accept multiple paths in one
+// call and report per-item success as an array of {uid, ok, error} — NOT via
+// a non-zero exit code. Confirmed live: a name collision at the destination
+// makes `filesystem move`/`filesystem copy` exit 0 with
+// [{ok:false, error:{name:"NodeWithSameNameExistsValidationError", ...}}].
+// Every one of these wrappers previously discarded the result outright, so a
+// collision was silently reported as success. Worst case was move(): it then
+// went on to rename whatever OTHER item happened to already be sitting at the
+// computed destination path — silently renaming an unrelated file while the
+// real source never moved.
+function assertItemsOk(result, action) {
+    if (!Array.isArray(result))
+        return;
+    for (const item of result) {
+        if (item && item.ok === false) {
+            const err = (item.error ?? {});
+            const code = typeof err.code !== "undefined" ? ` (code ${err.code})` : "";
+            throw new Error(`${action} failed: ${err.name ?? "unknown error"}${code} — likely a name collision at the destination.`);
+        }
+    }
+}
 // Strips "<package-name>@" and "+<hash>" from a version token like
 // "cli-drive@0.8.0+06e8c605", leaving "0.8.0". Falls back to the raw
 // token if it doesn't match, so an unexpected future format still shows
@@ -185,7 +206,8 @@ export class DriveService {
             await this.rename(sourcePath, dstName);
             return;
         }
-        await this.run(["filesystem", "move", sourcePath, dstParent]);
+        const moveResult = await this.run(["filesystem", "move", sourcePath, dstParent]);
+        assertItemsOk(moveResult, "Move");
         if (srcName !== dstName) {
             const movedPath = posixPath.join(dstParent, srcName);
             await this.rename(movedPath, dstName);
@@ -195,7 +217,7 @@ export class DriveService {
     // /trash or /photos-trash (the CLI rejects live paths). No --confirm flag
     // exists on the CLI side; our own confirmed-gate lives in the MCP layer.
     async delete(remotePath) {
-        await this.run(["filesystem", "delete", remotePath]);
+        assertItemsOk(await this.run(["filesystem", "delete", remotePath]), "Delete");
     }
     // Sharing
     //
@@ -285,16 +307,16 @@ export class DriveService {
         return this.list("/trash");
     }
     async trash(remotePath) {
-        await this.run(["filesystem", "trash", remotePath]);
+        assertItemsOk(await this.run(["filesystem", "trash", remotePath]), "Trash");
     }
     async restore(remotePath) {
-        await this.run(["filesystem", "restore", remotePath]);
+        assertItemsOk(await this.run(["filesystem", "restore", remotePath]), "Restore");
     }
     async emptyTrash() {
         await this.run(["filesystem", "empty-trash"]);
     }
     async copy(remoteSrc, remoteDst) {
-        await this.run(["filesystem", "copy", remoteSrc, remoteDst]);
+        assertItemsOk(await this.run(["filesystem", "copy", remoteSrc, remoteDst]), "Copy");
     }
     async listInvitations() {
         const result = await this.run(["invitation", "list"]);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "proton-drive-mcp",
-  "version": "1.0.34",
+  "version": "1.0.35",
   "description": "MCP server and CLI that gives Claude full access to Proton Drive — upload, download, share, and manage your end-to-end encrypted files without leaving the conversation.",
   "type": "module",
   "main": "dist/index.js",