What

Two defects in the image-upload IPC handler (packages/desktop/src/main/ipc/uploader.ts), found while investigating #3360 / #2915 — neither of them is the bug those issues report.

1. The image path was interpolated into a shell command (the real one)

uploadByPicgo ran exec(`${cmd} u "${localPath}"`), so a shell re-parsed the path: double quotes were consumed as quoting syntax, $name was expanded, and `x` was command substitution. A file named a "quoted" $name `x`.png — all legal characters on macOS/Linux — reached picgo as a quoted .png, which does not exist, so the upload always failed. A name containing $(…) or backticks would have executed.

The path now goes through as its own argv entry via execFile, which spawns no shell: each array element becomes one argv entry byte-for-byte. uploadByCli in the same file already did this; picgo is now consistent with it.

Reachable by: dragging a local image whose filename contains $, " or a backtick into a document with an uploader configured.

2. Concurrent uploads shared one temp file (hardening, not a reachable bug today)

writeBinaryToTmp named the file path.join(tmpdir(), Date.now() + ext), so two uploads starting in the same millisecond collide: one sends the other's bytes, and whichever finishes first unlinks the file the second still needs.

This is not reachable through the UI today — muya has exactly three imageAction call sites (paste, paste-over-selection, drag-drop), all single-image and all awaited, and a multi-file drop takes only files.find(...), the first image. It becomes a data-corruption bug the moment multi-image paste or drop is added. Each upload now gets its own mkdtemp directory, removed on cleanup; the basename stays timestamped because uploaders derive the remote filename from it.

Windows is deliberately untouched

The Windows branch keeps the original command string byte-for-byte. resolvePicgoBinary only ever returns the bare names picgo / picgo.exe there, so quoting ${cmd} would buy nothing, and this is the one platform the new spec does not cover.

What that branch does and does not protect against is now recorded in the comment: " is illegal in a Windows filename, so the injection fixed above is not reachable there, but %VAR% still expands inside double quotes, so a name like %TEMP%.png is still mangled. Fixing that needs real .exe-vs-.cmd resolution and a Windows machine to verify on — out of scope here.

Verification

Against the real picgo binary — old form vs new form, same filename:

OLD  exec(`picgo u "${path}"`)
  [PicGo WARN]: /tmp/mt-ab/a quoted  .png does not exist.

NEW  execFile(picgo, ['u', path])
  [PicGo WARN]: /tmp/mt-ab/a "quoted" $name `x`.png does not exist.

packages/desktop/test/unit/specs/uploader-temp-file.spec.ts is new — the uploader handler had no tests at all. It drives the real registered IPC handler against a stand-in uploader executable placed on PATH that records the path it was handed, and covers: the temp file keeps the image extension, the real bytes are written, the temp file is removed afterwards, two same-millisecond uploads get distinct paths, and a path with shell metacharacters arrives unmangled. The last two fail on develop.

Note on #3360 / #2915

The root cause those issues identified — path.join(os.tmpdir(), +new Date()) being handed a number, and the temp file having no extension — was already fixed in v0.19.0 (#3269 9309888b, and 624e69cb which moved upload into the main process and appended path.extname(name)). #3360 has since been verified against a real build and closed; #2915 was closed as its duplicate. This PR fixes two further defects on the same path and closes neither.

🤖 Generated with Claude Code