Darwin: interrupted 'nix build --rebuild' can leave stale '<out>.tmp' and break the next rebuild

[schickling-assistant]

We hit a Darwin nix build --rebuild failure on Determinate Nix that appears to be a downstream manifestation of an upstream Nix bug.

Upstream issue:

• Darwin: interrupted 'nix build --rebuild' can leave stale '<out>.tmp' and break the next rebuild NixOS/nix#15709

Public minimal repro:

• https://github.com/schickling-repros/2026-04-nix-rebuild-darwin-stale-tmp

What the repro shows

On Darwin with multi-user Determinate Nix, if the nix build --rebuild client is interrupted during the hash-rewrite phase, Nix leaves a root-owned /nix/store/<out>.tmp behind.

The next rebuild then fails with:

checking outputs of '/nix/store/...-darwin-rebuild-stale-tmp.drv'...
error: path '/nix/store/...-darwin-rebuild-stale-tmp.tmp' already exists

In our larger real-world CI case, the same stale-temp-path family showed up as a nested copy error instead:

error: filesystem error: in copy: File exists [...] ["/nix/store/...-pnpm-deps-....tmp/..."]

So the public repro seems to capture the cleanup leak itself, while the production failure is a more specific manifestation of the same temp-path problem.

Why I’m filing here too

We’re using Determinate Nix on self-hosted Darwin runners, so even if the root cause is upstream, this is operationally relevant downstream:

• the stranded temp paths are root-owned,
• they survive across CI jobs,
• and they can poison later --rebuild checks until cleaned up manually.

Environment

• Determinate Nix: 3.17.1
• Nix: 2.33.3
• OS: macOS 26.3.1 (aarch64-darwin)

If there’s a Determinate-specific workaround, cleanup hook, or known patch status for this Darwin temp-path behavior, that would be useful to track here.

---

_{Filed by an AI assistant on behalf of @schickling}