GitHub Flagged My Account as Spam for 58 Days. 93% of the Flagged Activity Came From GitHub's Own Copilot.

7 minute readManav Arya SinghUpdated

My GitHub account got restricted by automated abuse detection. I exported 19,173 rows of security log data and found 93% of the flagged OAuth activity came from GitHub's own Copilot integrations, not from me. Here's the data, the root cause, and what actually got the account back.

The restored GitHub profile for Manavarya09, showing 400 repositories and 5.1k total stars

On 25 June 2026 my GitHub account got restricted by an automated abuse detection system. My public repos vanished, my profile 404'd for anyone logged out, and OAuth logins that depended on GitHub stopped working, which took Vercel and Render down with them. One of the hidden repos was design-extract, which had roughly 3,400 stars at the time and active GitHub Sponsors.

It took 58 days to get it back.

Somewhere in the middle of that I exported my full GitHub security log, 19,173 rows, and found something I wasn't expecting. Almost all of the OAuth activity that looks like abuse on my account was generated by GitHub's own Copilot integrations. Not by me, and not by the AI tools I was actually using.

This post is the data, the root cause, and what actually moved the case. If you're here because your own account just got flagged, skip to what actually worked.

What triggered it

I use AI assisted development a lot, mainly Claude Code, and I commit at deliberately fine granularity so I can roll back to any logical step. Across two repos that came to about 80 and 60 commits. High volume, but every commit was real work.

That was my theory going in: high commit volume from AI tooling tripped a bot heuristic. Turns out that was only half of it, and the smaller half.

The data: 13,349 OAuth events and where they came from

GitHub lets you export your account security log as CSV. Mine was 19,173 rows. Filtering down to OAuth token lifecycle events, so create, destroy and regenerate, left 13,349 events. Biggest sources:

IntegrationEventsShare
Copilot Pull Request Reviewer8,92166.8%
Copilot Chat App2,78220.8%
Copilot SWE Agent7785.8%
ChatGPT Codex Connector2742.1%
Cursor1020.8%
Claude750.6%
Google Labs Jules690.5%

Those rows come to 13,001 of the 13,349, with the other 348 spread across smaller sources.

GitHub's own Copilot integrations account for 12,481 of 13,349 events. That's 93.5%.

Claude, the tool I was actually using all day and the one I assumed had caused all this, accounts for 75 events. Zero point six percent.

The destroy and regenerate reason codes are the giveaway:

  • expired, 2,535 events
  • max_for_app, 1,903 events

max_for_app means the app hit its own internal token ceiling. That's not a user hammering an API. That's Copilot's token pool repeatedly hitting a limit and churning tokens against itself.

There was also a spike of roughly 3,680 events between 6 and 9 April 2026, attributed to a generic launch/production user agent with no app name, no ID and no scopes. It traced back to Copilot PR Reviewer and Copilot SWE Agent, so it's an internal GitHub process, not anything running on my machine.

This is a known bug and they've acknowledged it

The behaviour is documented. microsoft/vscode#274418 describes exactly this. The Copilot extension hits its quota, the recovery path is broken, and it goes into a runaway loop of oauth_access.regenerate calls, which GitHub's own spam system then flags.

A VS Code engineer confirmed on that issue that it was a genuine token lifecycle bug and that a fix was in progress. Someone else on the same thread had their account fully disabled by it.

Two GitHub Community discussions describe the same thing independently. Discussion #191568 is a developer using Copilot, Cursor and Claude Code who got flagged for "suspicious activity" and resolved with the same boilerplate: "Our automated systems detected suspicious activity on this account. After review, we've removed the restrictions." Discussion #192402 is a second case citing the same heavy Copilot false positive pattern.

GitHub's own status page also logged multiple Copilot backend and auth incidents through June 2026, on the 17th, 23rd, 25th to 28th, and 1 July. Those line up exactly with the OAuth churn on my account.

The root cause

Three things stacked up.

First, genuinely high frequency AI assisted development. Real commits, fine granularity, unusual volume.

Second, the documented Copilot token lifecycle bug, which produced about 93% of the flagged OAuth activity and came entirely from GitHub's side.

Third, an automated abuse detection system reading the combined signal, high commit granularity plus enormous OAuth churn, as bot behaviour.

The bit I still can't quite get over is that the dominant signal in step two was produced by GitHub's own software, then flagged by GitHub's own abuse detection, on an account that hadn't done anything wrong.

What actually worked

Here's the honest version, including what didn't work.

These did nothing. [email protected] bounced and seems to be dead. Phone support doesn't exist. GitHub Sponsors has no separate channel and just routes into the same queue. Posting publicly at @github on X did nothing and gave the case no visibility at all. I thought about messaging a GitHub engineer on LinkedIn and decided not to, because they've got no access to moderation tooling and it looks like you're going around official channels.

What worked was slower and more boring.

I kept one main ticket alive. Ticket #4511409 was opened on day 0 and it's the one that eventually resolved on day 58. Every escalation I filed pointed back to it in the end.

I brought evidence instead of complaints. The security log breakdown plus the link to microsoft/vscode#274418 changed the case from "please trust me" to "here's the mechanism and it's documented on your side."

I filed a formal escalation ticket on day 47. It got a reply in about 40 minutes, after 31 days of silence on the original thread. It got archived two days later without resolving anything itself, but you could see it restart movement.

And I followed up on a schedule: days 11, 19, 29, 42 and 56. It resolved two days after the last one.

The reinstatement message was three lines. Activity was highlighted for manual review, restrictions cleared, full access restored.

If this is happening to you right now

Export your security log first, under Settings then Security log then Export. Filter to oauth_access events and group by integration. If your numbers look like mine, you've got your argument.

Look for the max_for_app and expired reason codes specifically. They point at the app churning tokens rather than you doing anything.

Cite microsoft/vscode#274418 and the community discussions above, because precedent matters here.

Keep everything on one ticket. Parallel threads get archived and merged anyway.

File a formal escalation once you're past about 30 days. That was the single biggest turning point for me.

And don't exaggerate the impact to force an escalation. Just state the real, verifiable consequences: blocked deployments, blocked OAuth logins, lost sponsorship income. That was enough.

The part that doesn't go in a table

I want to be straight about one thing, because it usually gets left out of posts like this.

Fifty eight days of silence on something you can't influence takes a toll. My work was frozen, sponsors were asking questions I had no answer to, and for most of it I genuinely didn't know if the account was coming back at all. There were weeks where it was the first thing I thought about in the morning and the last thing at night, and it messed with my sleep and my focus more than I expected.

If you're in the middle of this, the waiting is the hard part, and it isn't a reflection of you or your work. Keep your evidence tidy, follow up on a schedule, and try not to let a queue you can't see run your week. Mine did resolve in the end.

What I'd like to see change

The automated system isn't really the problem. False positives are unavoidable at GitHub's scale. Two things would have made this a three day case instead of a 58 day one.

Tell people what was detected. I was never told which signal tripped the flag. I had to reverse engineer it from my own logs.

And don't let first party integrations feed the abuse signal unweighted. When 93% of the abusive OAuth churn on an account comes from GitHub's own Copilot hitting a known bug, that should be filtered out before a human ever sees the account, let alone before it gets automatically restricted.

The account is fully restored and the repos are back. The sponsorship income for those two months isn't, and neither is the internship work that was blocked while it ran.

If you're building with AI coding tools daily and your commit volume looks unusual, pull your security log now, before anything happens. Then if it does happen, you've already got the evidence.

Common questions

Why does GitHub flag accounts that use AI coding tools?
In my case it wasn't the AI tool. It was high commit volume from AI assisted work plus a massive amount of OAuth token churn, and 93% of that churn came from GitHub's own Copilot integrations hitting a known token bug.
How do I find out what triggered my GitHub restriction?
Export your account security log as CSV from Settings, filter to oauth_access events, and group them by integration. Look for the destroy and regenerate reason codes, especially max_for_app and expired, which point at the app churning tokens rather than anything you did.
How long does a GitHub spam flag appeal take?
Mine took 58 days. Most reports I found while digging into this land around three to seven business days, so 58 is unusual but not unheard of.
Does emailing [email protected] work?
It bounced for me. There's no phone support either, and no separate GitHub Sponsors escalation channel. Everything ends up back in the same general ticket queue.