fix(queen): the swarm read GitHub anonymously and died on 403 half the day

[gHashTag]

The bees stop because the round dies. This is why, measured.

Measured, over the last twelve hours of production

minutes with zero bees working	357 of 721 (50%)
minutes with all four working	258 (36%)
median gap between bursts of work	22 min, against a 5-minute tick
longest gap	41.7 min
rounds ending GitHub returned 403 in one log window	144

The shape is bimodal — either four bees or none:

0 bees: 357 min (50%)
1 bees:  42 min  (6%)
2 bees:  19 min  (3%)
3 bees:  45 min  (6%)
4 bees: 258 min (36%)

A round either gets its issue list or dies whole. openIssues throws on a bad status, so one 403 takes the entire round with it — no review, no choice, no dispatch — and the capacity sits idle until some later round happens to get through.

The log makes it plain:

05:47:16 Queen tick decided → dispatch
05:50:32 Queen round starting   (no decision)
05:51:11 Queen round starting → Queen tick round failed  {"error":"GitHub returned 403"}
05:54:21 Queen round starting → Queen tick round failed  {"error":"GitHub returned 403"}
05:56:12 Queen round starting → Queen tick round failed  {"error":"GitHub returned 403"}
06:01:12 Queen round starting → Queen tick round failed  {"error":"GitHub returned 403"}
06:06:12 Queen round starting → Queen tick round failed  {"error":"GitHub returned 403"}
06:11:11 Queen round starting → decided, dispatched 4

The dispatch loop is not the problem — when a round survives, it fills all four slots in five seconds.

The cause

Every GitHub read in this file went out unauthenticated. The anonymous limit is 60 requests an hour, and this file has said so in a comment since it was written:

"a second round trip per candidate against an anonymous rate limit that is 60 an hour"

The limit was designed around instead of lifted. openIssues pages the backlog and bodiesFor fetches one body per candidate — twelve rounds an hour against a budget of sixty.

The token was in the environment the whole time. GH_TOKEN is set on this service and /rate_limit answers 15000 of 15000 remaining — the measurement that turns "we are being throttled" into "we are throttled at the anonymous tier while holding a key to the other one."

60/h → 15000/h.

What this is not

It hands nothing to a bee. This is the supervisor's own outbound read. The worker environment is still built from the ten-entry allowlist that deliberately excludes the GitHub token — untouched.

Falls back to anonymous when no token is set, so a local run without secrets behaves as it always has.

Tests

They pin the header, not the fetch — a test that mocked fetch would pass against a call that still forgot to ask for these headers. GH_TOKEN is checked first by name, because reading only GITHUB_TOKEN would leave the limit at sixty an hour on the one deployment that matters while every test still passed.

Verified locally by extracting the real helper from the committed source (this checkout cannot run the full server suite): 3 pass, 0 fail. CI is the witness for the suite.

🤖 Generated with Claude Code

[github-actions]

✅ Tests passed — 2064/2096

Suite	Passed	Failed	Skipped
✅ agent	87/87	0	0
✅ build	9/9	0	0
✅ cdp-protocol	5/5	0	0
✅ eval	93/93	0	0
✅ server-agent	272/272	0	0
✅ server-api	951/982	0	31
✅ server-browser	6/6	0	0
✅ server-integration	10/11	0	1
✅ server-lib	273/273	0	0
✅ server-pglive	3/3	0	0
✅ server-root	68/68	0	0
✅ server-skills	31/31	0	0
✅ server-tools	242/242	0	0
✅ shared	14/14	0	0

View workflow run

[gHashTag]

Two corrections to this PR, and a second defect the token alone does not fix

(Reposted: the first version of this comment lost every backticked identifier to shell command substitution. My mistake, and a good argument for --body-file.)

The burn rate, measured rather than estimated

The description said "twelve rounds an hour against a budget of sixty". Measured from inside the container while writing the follow-up:

t0  anonymous remaining 23/60, resets in 2352s
t1  anonymous remaining 14/60   (7 min later)
    burned 9 requests in 7 min  ->  about 77/hour

77 an hour against a limit of 60. The round makes about six calls, not two. And the paging loop does break on a short page, so my arithmetic was wrong in both directions — the real number is worse.

Once the budget is spent, every call 403s until the hourly reset. That is why the longest observed idle stretch was 41.7 minutes — it is the reset window, not a coincidence.

Side by side, right now:

anonymous : 200  remaining 23/60
with token: 200  remaining 14813/15000

It was expiry, not neglect

I framed this as a limit the author designed around instead of lifting. The doc comment is more honest than my framing:

"Anonymous on purpose: the repository is public, this is a read, and a token here would be a credential in a container for no gain. GitHub's anonymous rate limit is 60/hour against a loop that ticks at most a few times an hour."

The reasoning was sound. The loop ticks twelve times an hour now. The sentence outlived its assumption. It is kept in place and quoted rather than deleted — a rule that expired teaches more than one that was wrong.

The stated cost was also already paid: GH_TOKEN is on the supervisor, not a bee, and the worker allowlist that excludes it is untouched.

My own patch was sloppy

Inserting the helper immediately above openIssues split that function from its doc comment, leaving the paragraph about pagination and complete documenting a headers helper. Moved.

The second defect: one 403 killed the whole round

The token fixes the rate limit. It does not fix the fragility. openIssues threw on any bad status, so one refusal took the entire round — no review, no choice, no dispatch. 135 of 136 round failures were exactly that.

But this function already has a word for a partial answer: complete: false, which rememberIssues is built to respect, precisely so a truncated list is "still worth deciding against but never treated as the whole truth". A refusal on page two is that case. It now breaks and reports the pages it did get.

A refusal on page one still throws — a round with no issue list has nothing to decide against, and tolerating it would dispatch against an empty board.

Tests replace globalThis.fetch and restore it rather than using mock.module, which is process-global in bun and cannot be undone.