fix(canary): isolate TMPDIR so Gate A stops blocking healthy releases

[sanity]

Problem

Gate A blocked release v0.2.124 on a binary that was perfectly healthy. The gate was right to block on what it saw; what it saw was its own harness failing.

When it builds the client-API router, the node unconditionally create_dir_alls std::env::temp_dir()/freenet/webs (crates/core/src/server/client_api.rs, let contract_web_path =) and panics if that fails. temp_dir() reads only TMPDIR, so the path does not follow --data-dir, and the canary isolated HOME, config, data and log dirs but not TMPDIR — so it escaped the sandbox.

That directory is vestigial: grep -rn '"webs"' crates/ returns exactly one hit, the creation site. Nothing reads or writes it; web contracts are unpacked elsewhere (default_webapp_cache_dir). Its one surviving effect is the ability to abort startup. Filed separately as #5291 — this PR fixes the canary, not the node.

cross-compile.yml:638 stages the binary it is about to gate at /tmp/freenet. That is exactly the path the node then tries to create a directory under, so create_dir_all hit ENOTDIR against the binary file:

thread 'main' panicked at crates/core/src/server/client_api.rs:256:13:
Failed to create contract web directory at /tmp/freenet/webs: Not a directory (os error 20)

The node died (exit 101) before the update task spawned, so Gate A reported "the startup update check never ran" and refused to publish. Correct behaviour on the evidence available to it — the release stayed a draft, the fleet stayed on 0.2.123, and the dev-room alarm fired. But the shipping binary was fine.

Two things made this land at the worst moment: the harness had never run in real CI before it gated a real release, and local validation (4/4 green pre-merge) ran the binary from target/release/freenet, where the collision cannot occur.

Approach

Set TMPDIR to a directory inside the canary's own workdir, scoped to the subshell that launches the node, so only the throwaway node is affected.

Correction to an earlier revision of this description. It claimed "relocating the binary alone is not sufficient." That was wrong, and review disproved it by testing: with the pre-fix script, a clean scratch TMPDIR containing no freenet entry, and the binary staged outside it, the same artifact returns rc=0. Relocating the binary in cross-compile.yml alone would have unblocked v0.2.124. The contrary evidence came from a host-specific condition over-generalised — /tmp/freenet on the test host is a directory owned by another user, so that run hit EACCES rather than the file collision.

Isolation is still the better fix, for the narrower and true reason: relocation cures the CI symptom while leaving the canary non-self-contained, so on any machine where $TMPDIR/freenet is owned by someone else — a shared host, or one already running a node under a service account — the node still panics. Isolation removes the dependency on what happens to be in the ambient temp dir.

It also closes the second half of this file's own isolation claim. The ports half was corrected earlier (the runs bind real ports and collide with a running node); this is the other half — until now two nodes on one machine shared /tmp/freenet/webs, so the header's "keeps its files to its own temp directory" was false.

Testing

Verified against the shipped v0.2.124 artifact, downloaded from the draft release (0.2.124 (6d39f89b9207)), staged at $TMPDIR/freenet to reproduce the exact collision. CI staged it at /tmp/freenet literally; that path is an unwritable directory on the test host, so TMPDIR was pointed at a scratch dir with the binary inside it — same mechanism, reproducible without root.

Case	Result
Fixed	rc=0 — OK: the node compared against '0.2.123', which matches GitHub's latest release. and OK: startup update check ran to completion and parsed GitHub's response.
Control (fix reverted, same collision)	rc=1, node exited with code 101, panicked at client_api.rs:256, Failed to create contract web directory at …/freenet/webs: Not a directory (os error 20)

The control reproduces the production failure exactly, so this is a before/after with a working negative case rather than an assertion that it should help.

A separate run — same artifact, non-colliding binary path, default TMPDIR, on a host where /tmp/freenet is another user's directory — also failed. That is the EACCES case, not the ENOTDIR one, and it is host-specific; see the correction above. Both are startup panics reported by Gate A as "the startup update check never ran", which is the hard-fail branch, not the INDETERMINATE/UNVERIFIED branch the script keeps carefully distinct.

Regression coverage. The four suites were all green while this bug shipped, because they drive a bash fake node with no web directory. Added: a behavioural lifecycle case in which the fake node is the regular file staged at $TMPDIR/freenet, so the ENOTDIR comes from the kernel rather than being simulated — red before the fix, green after. A source-scrape pin is included too, but the behavioural case is the load-bearing one: a pin cannot distinguish export TMPDIR="$work/tmp" from export TMPDIR=/tmp. A companion case asserts the full env handed to the node, closing a sibling gap where deleting export HOME= also left every suite green.

Not fixed here, deliberately

• The node hardwiring its web dir to $TMPDIR/freenet/webs regardless of --data-dir. That is arguably a product bug — a node's files escaping its configured data dir — but changing it affects every node, not just the canary, and belongs in its own PR with its own review. Filed separately.
• Gate A runs downstream of cargo publish. v0.2.124's crates are on crates.io while its GitHub release is still an unpublished draft, because the gate sits after the one irreversible step. A Gate A block should cost a re-run, not a version number. Filed separately; it needs an ordering change in release.yml/cross-compile.yml, not a one-line patch.
• The canary has never run outside a release. Its first live exercise was the release it was gating. A continuous run on main — with mechanically identical staging, or it proves nothing — would surface harness faults where they are cheap. Filed separately.

Refs #5222, #5236.

[AI-assisted - Claude]

[github-actions]

Rule Review: TMPDIR isolation fix — no blocking issues

Rules checked: git-workflow.md
Files reviewed: 5 (.github/workflows/ci.yml, docs/RELEASING.md, scripts/auto-update-canary.sh, scripts/auto-update-canary_lifecycle_test.sh, scripts/auto-update-canary_test.sh)

This is a fix:-scoped PR. It satisfies the regression-test requirement with two behaviorally-distinct lifecycle test cases (case 9: a real ENOTDIR reproduction via a fake node staged at $TMPDIR/freenet; case 10: an environment-dump assertion that reads the value the node actually received) plus a cross-file source pin, and the commit messages document mutation-testing results (fixed vs. reverted-fix control) confirming the tests fail without the fix. All commit subjects use valid conventional-commit prefixes (fix, test, docs, ci).

Warnings

None.

Info

• .github/workflows/ci.yml:20 — This PR bundles a change to the CI's own "fix PR must include a regression test" detector (adding the ok helper alongside check) into a PR whose primary subject is TMPDIR isolation. It's well-motivated (the new lifecycle tests use ok/bad and would otherwise be invisible to that gate) and documented inline, but it's a distinct concern from the canary fix itself — worth a reviewer's explicit sign-off that this doesn't read as scope creep under the "one logical change per PR" guidance, even though it's arguably necessary for this same PR's CI to pass correctly.

---

Rule review against .claude/rules/. WARNING findings block merge.