no-op cargo build adds latency to binary relaunch on macOS

Problem

On macOS, cargo build appears to always rewrite the binary file on disk, even when the contents have not changed.

This has a performance cost: macOS detects the new file as unverified, and runs a malware scan on first launch. On my machine, this costs about 130ms of extra latency on the first run of the rebuilt binary. That's for a trivial binary; for larger binaries, the cost can scale with size. This is relevant for a workflow that always rebuilds outputs before running them, as a simple way to ensure that the running binaries are not stale.

To make that a bit more concrete: cargo run pays this latency cost on every run, even when the output has not changed.

Steps

1. cargo build a binary
2. run the binary: observe a first-run penalty
3. rerun the binary: observe no second-run penalty
4. cargo build to rebuild (should be a no-op)
5. run the binary: observe the first-run penalty reoccurs

Possible Solution(s)

The performance cost could likely be avoided by simply skipping the file overwrite when that would be a no-op. I have not yet validated this proposed fix.

Notes

Note: This issue was discovered by Claude Code, when I asked it to minimize latency for my workflow. The mechanism that Claude identified makes sense to me, and I have independently validated the numbers:

$ cd "$(mktemp -d)" && cargo new --quiet recopy-demo && cd recopy-demo

$ cargo build --release --quiet

$ stat -f %i target/release/recopy-demo
...1810

$ cargo build --release --quiet

$ stat -f %i target/release/recopy-demo
...2039

$ time target/release/recopy-demo
Hello, world!
target/release/recopy-demo  0.00s user 0.00s system 2% cpu 0.138 total

$ time target/release/recopy-demo
Hello, world!
target/release/recopy-demo  0.00s user 0.00s system 70% cpu 0.008 total

--

Relevant context, identified by Claude:

• cargo#10196 (https://github.com/rust-lang/cargo/pull/10196): why macOS copies instead of hard-linking
• cargo#15908 (https://github.com/rust-lang/cargo/pull/15908): related context on first-launch slowness on macOS
• Zulip thread (https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F/near/535948902): discussed the malware scan, precedes cargo#15908
• users.rust-lang.org thread 117450 (https://users.rust-lang.org/t/cargo-run-slow-on-macos-when-binary-already-built/117450): an earlier report of this same issue, in a different forum

--

Further unverified claims from Claude, though they all look reasonable to me:

• Why only macOS: On other platforms cargo hard-links the binary and skips the step when the link is already in place. On macOS it copies, and that skip can never match a copy. crates/cargo-util/src/paths.rs:_link_or_copy appears to drive the distinction on macOS vs. Linux.
• Not everyone will see the delay. If a terminal is allowlisted under Developer Tools to disable malware scans, then both runs come out fast, though the stat numbers still change.

Version

$ cargo version --verbose
cargo 1.98.0 (797e8a9bc 2026-08-05) (Homebrew)
release: 1.98.0
commit-hash: 797e8a9bca276c1c9f9f738d2a20f484fa4eea9d
commit-date: 2026-08-05
host: aarch64-apple-darwin
libgit2: 1.9.7 (sys:0.21.0 system)
libcurl: 8.7.1 (sys:0.4.90+curl-8.21.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 26.6.2 [64-bit]