[Aschenbath]

Closes #37116

deno upgrade unpacks the new binary into a directory from tempfile::TempDir::new() and runs it there (check_exe) before replacing the current executable. When the system temp directory is mounted noexec, running it fails with Permission denied (os error 13). That is a common hardening setup for /tmp.

This creates that directory next to the output executable instead, as .deno-upgrade-XXXXXX in the directory of the current deno or of --output. That directory has to be writable for the upgrade anyway. It also keeps the new binary on the same file system as its destination, so replace_exe can rename it into place. If the directory can't be created there (it doesn't exist, or isn't writable, e.g. a --dry-run of a deno in /usr/bin), it falls back to the system temp directory as before. TempDir still removes it afterwards.

Only the regular upgrade path changes. --pr and --branch still download into the system temp directory.

Testing

• Added unit tests for the new helper: the directory is created in the output executable's directory and removed on drop, and it falls back to the system temp directory when the output directory is missing.
• cargo test -p deno --lib -- tools::upgrade::test passes (31 tests). cargo clippy -p deno --lib --tests -- -D warnings and cargo fmt --check are clean.
• I built and tested on Windows. I didn't reproduce the noexec failure end to end on Linux.

AI disclosure

This PR was written primarily by Claude Code (Claude Opus 5.5), including the change, the tests and this description. It has not yet been reviewed by a human.

🤖 Generated with Claude Code

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}