work-on-issues in standalone mode has no count cap and no actor check, and the wrapper fans out one subagent per discovered issue. So the number of agent runs on a given night is set by however many issues carry the night-shift label — by anyone with triage or push access, at any time, with no ceiling.
The two properties that combine
No count cap, stated deliberately. The task file says it three times, most explicitly at line 187: "No count cap. When the wrapper dispatches you, it has already picked one issue for you. When you're running standalone, work every discovered tagged issue." And line 8: "discover all tagged issues yourself and process every one of them. There is no count cap."
No actor check is possible. The nightly routine reads label state, not the event that produced it. There is no sender to check — unlike the claude-task path in the owner's own repo, which gates on github.event.sender.login and is therefore safe by construction. That difference is worth stating plainly: one path is protected because it is event-driven, the other cannot be protected the same way because it is state-driven.
So the label is the cap, and the label is writable by more people than the person whose account pays for the run.
Why this is newly live rather than theoretical
Until 2026-08-13, zero issues across the two boilerplates carried the night-shift label — 0 of 75. The path was dormant, so the missing cap cost nothing. Four labels were applied to sanity-nextjs-boilerplate on 2026-08-14 (#323, #328, #298, #306), chosen deliberately as small, single-purpose, decision-free work. That repo has three collaborators besides the owner with push/triage: borgenk, erlendstromsvik, truls1502.
None of that is a trust problem, and the issue should not be read as one. The realistic case is a colleague seeing a label that looks like triage metadata, agreeing that twenty issues are good Night Shift candidates, and labelling them — which is a reasonable thing to do with a label whose name gives no hint that applying it spends someone's model allowance overnight.
What would fix it
A per-repo, per-night ceiling enforced by the runner rather than by convention. Concretely: discovery finds M tagged issues, the run works the N oldest (N small — 5 is a sensible default), and it logs that M − N were skipped, naming them.
The logging half is not decoration. A cap that silently truncates converts "twenty issues were labelled" into "five got PRs and nobody knows what happened to fifteen", which is worse than no cap, because the missing work is invisible rather than merely delayed. Per the workspace convention this repo already follows elsewhere: a bounded scan says what it dropped.
Two smaller things worth deciding at the same time:
- Order. Oldest-first is predictable and drains a backlog; newest-first serves the person who just labelled. Oldest-first is the better default precisely because it is not steerable by whoever labelled most recently.
- Where the number lives. A constant in the task file is fine and cheap. Per-repo configuration is tempting but adds a config surface for a number that will realistically be the same everywhere.
Related
Sibling of #39 (no issue-vs-issue pass before the fan-out) and #40 (a skip permanently silences the issue). All three concern what happens around the per-issue work rather than the work itself, and all three get sharper as labelling expands beyond the four issues currently carrying it.
work-on-issuesin standalone mode has no count cap and no actor check, and the wrapper fans out one subagent per discovered issue. So the number of agent runs on a given night is set by however many issues carry thenight-shiftlabel — by anyone with triage or push access, at any time, with no ceiling.The two properties that combine
No count cap, stated deliberately. The task file says it three times, most explicitly at line 187: "No count cap. When the wrapper dispatches you, it has already picked one issue for you. When you're running standalone, work every discovered tagged issue." And line 8: "discover all tagged issues yourself and process every one of them. There is no count cap."
No actor check is possible. The nightly routine reads label state, not the event that produced it. There is no sender to check — unlike the
claude-taskpath in the owner's own repo, which gates ongithub.event.sender.loginand is therefore safe by construction. That difference is worth stating plainly: one path is protected because it is event-driven, the other cannot be protected the same way because it is state-driven.So the label is the cap, and the label is writable by more people than the person whose account pays for the run.
Why this is newly live rather than theoretical
Until 2026-08-13, zero issues across the two boilerplates carried the
night-shiftlabel — 0 of 75. The path was dormant, so the missing cap cost nothing. Four labels were applied tosanity-nextjs-boilerplateon 2026-08-14 (#323, #328, #298, #306), chosen deliberately as small, single-purpose, decision-free work. That repo has three collaborators besides the owner with push/triage:borgenk,erlendstromsvik,truls1502.None of that is a trust problem, and the issue should not be read as one. The realistic case is a colleague seeing a label that looks like triage metadata, agreeing that twenty issues are good Night Shift candidates, and labelling them — which is a reasonable thing to do with a label whose name gives no hint that applying it spends someone's model allowance overnight.
What would fix it
A per-repo, per-night ceiling enforced by the runner rather than by convention. Concretely: discovery finds M tagged issues, the run works the N oldest (N small — 5 is a sensible default), and it logs that M − N were skipped, naming them.
The logging half is not decoration. A cap that silently truncates converts "twenty issues were labelled" into "five got PRs and nobody knows what happened to fifteen", which is worse than no cap, because the missing work is invisible rather than merely delayed. Per the workspace convention this repo already follows elsewhere: a bounded scan says what it dropped.
Two smaller things worth deciding at the same time:
Related
Sibling of #39 (no issue-vs-issue pass before the fan-out) and #40 (a skip permanently silences the issue). All three concern what happens around the per-issue work rather than the work itself, and all three get sharper as labelling expands beyond the four issues currently carrying it.