Blackbox Blast
BB Preflight
← Incident log

CASE · Major · runaway-loop

Unverified reportCollected from public reports

Fixing 15 repositories in parallel got a GitHub account suspended for six days (unverified report)

Per the author, 15 Claude Code subagents were fixing the author's own 15 public repositories at the same time when, partway through the fifth round of fixes, every GitHub API call started returning 403 and the account turned out to be suspended for a Terms of Service violation.

4 min read

OBSERVED
CATEGORY
runaway-loop
BLAST RADIUS
uptime
DETECTED BY
manual-observation
TAGS
#claude-code #github #account-suspension #subagents #parallelism #rate-limit #acceptable-use-policy

CH 1

Cause

GitHub never said which rule applied, so the cause is the author's guess. In one day the agents opened about 50 PRs, pushed to each many times, polled CI results through the API every few tens of seconds, and re-ran failed CI. The work touched only the author's own repositories, but the author thinks it may have looked like the excessive automated bulk activity the Acceptable Use Policies prohibit.

CH 2

Consequence

The suspension lasted about six days. During that time the repositories and PRs were hidden from view, and the GitHub Pages site published from the same account could not be reached. Zenn articles linked to GitHub could not be updated, and scheduled tasks that used GitHub failed every run. It also took about half a day from noticing to filing an appeal.

CH 3

Fix

The author filed a reinstatement request, answered support's question about how the account would be used with its purpose and future limits, and was reinstated six days later. To prevent a repeat, the author wrote limits into the agent instruction file: at most two concurrent write tasks, one push after tests pass, PRs at least a minute apart with at most 10 PRs and 30 pushes a day, CI checks at least two minutes apart, and stop without retrying on 403, 429 or a secondary rate limit.

LOGTimeline

  1. OCCURRED

    Date of record (date_observed)

  2. DETECTED

    1 day after it occurred · Detected by: manual-observation

  3. RESPONDED

    6 days after detection

Built only from the dates on record (date_observed, date_detected, date_resolved).

What happened

The author had Claude Code fixing bugs, adding tests and tidying the documentation in 15 of their own public repositories. One subagent was assigned to each repository, all 15 ran at once, another AI scored the results, and the loop of fixing until the score went up ran for many rounds. Per the author, at around midnight on October 9, 2026 (Japan time), partway through the fifth round, every GitHub API call started returning 403 and the account had been suspended for a Terms of Service violation.

The chaos on the ground

Between midday and late night on October 8, the agents had opened about 50 PRs, pushed to each of them many times, polled CI results through the API every few tens of seconds, and re-run failed CI. The author looks back on it as a volume and speed no human working by hand could reach.

Right after noticing the suspension, the author was locked out after being told sign-ins kept failing, and only saw the suspension screen in the morning. It did not say which rule had been broken. Because it was the middle of the night, sign-in was restricted, and the appeal form took time to find, it was about half a day before an appeal went in.

The impact was wider than expected. The repositories and PRs were hidden from view (not deleted), and the GitHub Pages site published from the same account could not be reached. Zenn articles linked to a GitHub repository could not be added or edited, and scheduled tasks that used GitHub failed every run. The author writes that putting many things on one account means they all stop together.

Root cause

GitHub never said specifically which rule applied, so what follows is the author's guess. GitHub's Acceptable Use Policies prohibit excessive automated bulk activity and placing undue burden on its servers through automated means. The work was honest fixing aimed only at the author's own repositories, but the author thinks the burst of PRs, pushes and API calls in a short time may have looked like exactly that to an automated system. Support also explained that the account had tripped an abuse-detection system and was being reviewed by hand.

The author mentions one more possibility: free accounts are limited to one per person, with a single separate machine account allowed for automation. The author did, however, tell support that this was the only GitHub account they use.

The fix

The author chose a reinstatement request, which asks for the account back in exchange for fixing the problem, and wrote in English that they had been using an AI agent on their own repositories, had written nothing to anyone else's, and would cut volume and speed. A few hours later support asked how the account would be used, and the author answered with its purpose, the fact that they decide merges themselves, and concrete limits going forward. The restriction was lifted on the morning of October 15, about six days including a weekend. The author warns that opening another account to keep working during a suspension could be treated as evading it.

To prevent a repeat, the author drew on GitHub's REST API best practices and wrote limits into the agent instruction file. At most two tasks that write to GitHub run at once, with repositories handled in turn. A push happens only after tests and lint pass locally, as a rule once per PR. PRs are opened at least a minute apart, with at most 10 PRs and 30 pushes a day; anything beyond that waits until the next day. CI results are awaited through notifications, and when checked directly, at least two minutes apart. Each CI job is re-run at most once. On 403, 429 or a secondary rate limit, the agent stops without retrying and reports. Work is split into 3 to 5 repositories a day, and important things are not all kept on one account.

The lesson for operators: when handing an external service to an agent, decide limits on how many run at once and how fast they write, along with what they may touch. Even work on your own repositories is not told apart from abuse once the volume is high enough.

Sources

PREFLIGHTIs your own Mac prepared?BB Preflight is a free Mac tool that checks 21 things, from AI agent permissions to where your keys live, without changing anything.Run the check →