skills(running-tend): note cargo needs $HOME/.cargo/env in the tend sandbox

[worktrunk-bot]

What

Adds a note to the running-tend Test Commands section that cargo is installed at $HOME/.cargo/bin but not on the tend sandbox's default PATH, so the first bare cargo … call in a run fails with cargo: command not found. The fix is to source $HOME/.cargo/env (or prepend $HOME/.cargo/bin to PATH) before the first cargo command instead of discovering the location after a failure.

Why

This is a recurring, structural papercut: any tend run that compiles Rust in the sandbox hits it, and the model then spends a probe + retry recovering. It fired twice in the 24h window ending 2026-07-04, in two different workflow types:

• tend-nightly 28698827380: cargo check --lib → cargo: command not found → probe (command -v rustc; ls ~/.cargo/bin; … [ -f "$HOME/.cargo/env" ]) → retry with . "$HOME/.cargo/env".
• tend-mention 28699086393 (applying a review suggestion on docs(remote_ref): include Gitea in provider trait docstrings #3360): cargo check --lib → cargo: command not found → probe ({ [ -f "$HOME/.cargo/env" ] && . …; }; which cargo …; export PATH="$HOME/.cargo/bin:$PATH") → retry.

Plus two prior occurrences recorded in the review-runs tracking issue #3349 (the "cargo discovery dance" first logged 2026-06-29 and again 2026-07-01), where earlier runs deferred the note because the manifestations were preemptive probes rather than actual failures. This window both occurrences were real cargo: command not found failures, and the pattern now spans nightly and mention — not just nightly — so the earlier watch's escalation condition is met.

Gate assessment

• Confidence: structural failure (cargo is deterministically absent from the sandbox PATH), 4 total occurrences across two weeks and two workflow types (2 this window + 2 historical). Passes Gate 1.
• Magnitude: a targeted note (one short paragraph + one command) in an existing section. Passes Gate 2 even at the "new paragraph" bar (3+ occurrences).

Verification

The added command matches exactly what both recovering runs used to fix their PATH (. "$HOME/.cargo/env" / export PATH="$HOME/.cargo/bin:$PATH"). The probe outputs confirm ~/.cargo/bin contains cargo and $HOME/.cargo/env exists in the sandbox. Documentation-only change to a skill overlay — no code, no tests.

[worktrunk-bot]

The core guidance is correct and matches what I see running in this same sandbox: cargo is a rustup shim at $HOME/.cargo/bin/cargo, that directory is absent from PATH, and $HOME/.cargo/env exists — so sourcing it before the first cargo call is the right fix.

One factual correction: the closing parenthetical claims rustc/clippy are already on PATH. They aren't. In the sandbox the entire toolchain (rustc, clippy-driver, cargo-clippy, rustfmt, cargo) lives in $HOME/.cargo/bin, and none of them are on PATH (verified: PATH contains no .cargo/bin, and command -v rustc returns nothing). Leaving the line as-is could send a future run down exactly the probe-and-retry path this note is meant to prevent — e.g. a bare rustc --version toolchain check would also fail. Sourcing the env fixes all of them at once, so the suggestion reflects that.

[max-sixty]

@worktrunk-bot review pls

[worktrunk-bot]

Reviewed. The core guidance is correct — I verified it in this same sandbox: cargo, rustc, clippy-driver, and rustfmt all live in $HOME/.cargo/bin, that directory is absent from PATH, and $HOME/.cargo/env exists, so sourcing it before the first cargo call is the right fix.

One factual error remained from the earlier review pass: the closing parenthetical claimed rustc/clippy were already on PATH. They aren't — command -v rustc returns nothing here, and PATH contains no .cargo/bin entry. Leaving it would send a future run down exactly the probe-and-retry path this note is meant to prevent (a bare rustc --version toolchain check would also fail). I pushed 634ecdc rewriting the parenthetical to say the whole toolchain is off PATH and that sourcing the env fixes all of it at once. With that, the note is accurate and ready to merge.

Verification

command -v cargo         → (nothing)
command -v rustc         → (nothing)
command -v clippy-driver → (nothing)
ls $HOME/.cargo/bin      → cargo cargo-clippy clippy-driver rustc rustfmt rustup …
test -f $HOME/.cargo/env → yes
PATH contains .cargo/bin → no

[max-sixty]

can we fix by setting this up better?

[worktrunk-bot]

Good instinct — and yes, this should be fixed at the source rather than papered over in the skill. But the source isn't in worktrunk; it's the tend sandbox, and worktrunk can't reach the lever. Here's what I found tracing it in this same sandbox:

Root cause. The agent runs as a separate tend-sandbox user whose PATH is hardcoded in the upstream action — proxy/setup-sandbox.sh writes the launch env:

PATH=${AGENT_HOME}/.local/bin:/usr/local/bin:/usr/bin:/bin

The toolchain is present in the sandbox home — ~/.cargo/bin has cargo, rustc, clippy-driver, rustfmt (all rustup shims) — it's just not on that PATH. So it's a one-line omission, not a missing install:

$ whoami            → tend-sandbox
$ command -v cargo  → (nothing)
$ ls ~/.cargo/bin   → cargo  clippy-driver  rustc  rustfmt  rustup …   (cargo -> rustup)
$ test -f ~/.cargo/env → yes

Why worktrunk can't fix it locally. The sandbox env is rebuilt from scratch (sudo env … replaces the environment), and GITHUB_ENV/GITHUB_PATH are deliberately excluded from the handoff to keep the sandbox from writing into later runner steps. So nothing claude-setup or a workflow sets on the runner side propagates into the sandbox's PATH. There's no repo-local hook that reaches it — the note is the only worktrunk-side mitigation available.

The proper fix is one line upstream in max-sixty/tend's proxy/setup-sandbox.sh: append ${AGENT_HOME}/.cargo/bin to that hardcoded PATH (guarded on the dir existing, so it's inert for non-Rust adopters). That fixes it for every Rust project using tend, not just here, and removes the probe-and-retry dance entirely. The generated-workflow header points at https://github.com/max-sixty/tend/issues as the channel for exactly this kind of upstream change — I've left it for you to file rather than opening a cross-repo issue autonomously.

Recommendation: merge this note as the interim mitigation (it's accurate and cheap), and land the setup-sandbox.sh one-liner upstream; once that ships, the note becomes redundant and can be dropped.