You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was created automatically. Close it once every row above is drained — each stranded trigger re-run, or confirmed no longer needed. The tend-review-runs sweep does that where it runs.
Drained by the tend-review-runs sweep. Cause found and already resolved; two rows need a fresh trigger, noted below.
Cause
All ten rows are the same failure: tend 0.1.19 discarded the runner's PATH across the sandbox privilege boundary, so .config/tend.yaml's sandbox_setup: line uv tool install --quiet pre-commit died with bash: line 4: uv: command not found (exit 127) and the agent never booted.
Clean bisection on the action pin — 0.1.18 green at 15:14Z, all ten failures on 0.1.19, green again on 0.1.20 at 23:51Z:
Run max-sixty/tend/claude@0.1.18 # 33086703145, 15:14Z, success
Run max-sixty/tend/claude@0.1.19 # 33127253361, 23:45Z, failure (last of ten)
Run max-sixty/tend/claude@0.1.20 # 33127767243, 23:51Z, success
This is the upstream regression fixed by max-sixty/tend#1071 ("Preserve setup-added tool paths in the Claude sandbox") and shipped in 0.1.20, which landed here in #3940 at 23:51Z. No adopter-side change is needed — .config/tend.yaml and .github/actions/tend-setup/action.yaml were both correct throughout, and main has been on 0.1.20 since.
gh run rerun would reproduce the failure rather than drain it. A re-run uses the workflow file from the original run's commit, and that commit pins the broken version:
$ gh api repos/max-sixty/worktrunk/actions/runs/33087715330 --jq '{event, head_sha}'
{"event":"issues","head_sha":"37141b8eb10bfafde1d127f497545b8c621a7409"}
$ git show 37141b8eb:.github/workflows/tend-triage.yaml | sed -n '49p'
- uses: max-sixty/tend/claude@0.1.19
So each re-run would fail the same way and file a fresh row here, on an incident that is already over. What recovers each one instead:
Wrong template values when is using wt switch pr:<number> #3934 (robsonpeixoto's report, opened 15:25Z, still at zero comments) — tend-triage fires only on issues: [opened], so nothing can re-fire it. An @worktrunk-bot mention on the issue is the only path.
Color homepage command comparison #3939 — tend-review includes reopened in its trigger types, so a push or a close/reopen re-fires it. It's your PR, so that's your call rather than something this sweep should do.
Closing so the next outage opens a clean incident rather than folding into this one. The gh run rerun gap is reported upstream on max-sixty/tend#1066.
Activity
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 27, 2026
worktrunk-bot commentedon Aug 28, 2026
Drained by the
tend-review-runssweep. Cause found and already resolved; two rows need a fresh trigger, noted below.Cause
All ten rows are the same failure:
tend0.1.19 discarded the runner'sPATHacross the sandbox privilege boundary, so.config/tend.yaml'ssandbox_setup:lineuv tool install --quiet pre-commitdied withbash: line 4: uv: command not found(exit 127) and the agent never booted.Clean bisection on the action pin — 0.1.18 green at 15:14Z, all ten failures on 0.1.19, green again on 0.1.20 at 23:51Z:
This is the upstream regression fixed by max-sixty/tend#1071 ("Preserve setup-added tool paths in the Claude sandbox") and shipped in 0.1.20, which landed here in #3940 at 23:51Z. No adopter-side change is needed —
.config/tend.yamland.github/actions/tend-setup/action.yamlwere both correct throughout, andmainhas been on 0.1.20 since.Row status
Why the two remaining rows were not re-run
gh run rerunwould reproduce the failure rather than drain it. A re-run uses the workflow file from the original run's commit, and that commit pins the broken version:So each re-run would fail the same way and file a fresh row here, on an incident that is already over. What recovers each one instead:
wt switch pr:<number>#3934 (robsonpeixoto's report, opened 15:25Z, still at zero comments) —tend-triagefires only onissues: [opened], so nothing can re-fire it. An@worktrunk-botmention on the issue is the only path.tend-reviewincludesreopenedin its trigger types, so a push or a close/reopen re-fires it. It's your PR, so that's your call rather than something this sweep should do.Closing so the next outage opens a clean incident rather than folding into this one. The
gh run rerungap is reported upstream on max-sixty/tend#1066.