A company co-founder says someone outside their GitHub organization deleted one of its private repositories. The account had no membership, invite or role, they say, and nothing in the organization or enterprise audit logs explains how it got access. The only trace is a single repo.destroy event from the GitHub CLI. The repository is not in the deleted repositories list, so it cannot be restored. International Cyber Digest amplified the claim on October 28, 2026, and replies to it include at least one other user describing a similar deletion days earlier.
This is not the first report of this kind, and we have not seen GitHub's side, so we cannot verify any of it independently. We deliberately do not name the company. This post separates what the shared log shows from what people are guessing, and lists what to check in your own organization.
Quick answers
| Question | Answer |
|---|---|
| What was deleted? | One private repository in a company's GitHub organization. |
| When? | October 27, 2026, 11:50:22 +05:30, per the log. |
| How? | One repo.destroy via the GitHub CLI using an OAuth access token. |
| Is it confirmed as a GitHub flaw? | No. GitHub has not commented in what we saw. |
| Can it be restored? | The owner says no; it is missing from deleted repositories. |
| Is this the only report? | No. Other users describe similar deletions; we have not verified them. |
| Do customers need to act? | Nothing reported. Deletion is not the same as data theft; the log shows no read or clone. |
Claimed vs verified
| Claim | Status | Source |
|---|---|---|
| A private repo was deleted | Reported by the owner | The owner's post and log screenshot |
| The actor has no org membership, invite or role | Claimed, not independently checked | The owner; the log shows actor_is_bot: false |
One repo.destroy call from the GitHub CLI | Shown in the screenshot | Audit log fields request_method: delete, user agent GitHub CLI |
| Authenticated with an OAuth access token carrying a delete scope | Shown in the screenshot | Fields programmatic_access_type and token_scopes (delete_repo appears among them) |
| Nothing in org or enterprise logs granted access | Claimed | The owner; we have not seen those logs |
| Repo cannot be restored | Reported | The owner |
| This is a GitHub vulnerability ("new GitHub RCE") | Unconfirmed, speculation in replies | Reply posts only |
| A coding agent did it | Unconfirmed, speculation in replies | One commenter, no evidence shared |
| Others have had repos deleted the same way | Unverified | Replies describing a similar deletion days earlier; no logs shared |
Parts of the screenshot are blurred, including the actor name, token identifiers and the hashed token. We do not repeat anything we cannot read.
What the log tells us
The visible fields describe a deliberate API call, not a web click: request_category: api, request_method: delete, and a user agent identifying the GitHub CLI. The token_scopes field lists scopes including delete_repo, which is not part of the default gh auth login flow; gh asks for it only when you run gh auth refresh -s delete_repo. So whoever ran this had deliberately added that scope to their token.
That matters. A token with delete_repo can delete any repository its owner can administer. The question is therefore not how the token deleted the repo, but why that account had admin rights over it.
How it might have happened
None of these is confirmed. They are the explanations we would test, most likely first.
- Outside-collaborator access. An account can hold a role on a single repository without being an organization member. Admin on one repo is enough to delete it, subject to the org's repository-deletion setting. An old invite accepted months ago, or a contractor added per repo, would look like "no role" in a member list. Check the repository's Collaborators page and the org's Outside collaborators list.
- A repository moved between owners. Repositories transferred into the org, or created under a personal account first, can leave stale access behind. Review each repo's access history for the transfer.
- A leaked or shared token. An OAuth token from the GitHub CLI can sit in a laptop keychain, a CI secret, a dotfile or a pasted log. If the actor's own account had legitimate access somewhere, a stolen token would reuse it. Infostealers that harvest developer credentials make this realistic; see Aokigahara, which targets Claude Code, Codex and Cursor credentials.
- An automated agent or script running under that account. If the account holder ran a coding agent with a broad
ghlogin, a bad instruction or prompt injection could trigger a delete. That is the commenter's theory. It is plausible in general and unsupported here, since the actor is a separate person from the company's staff. - Audit-log attribution or display issues. Logs can mislabel the org or role context for tokens approved through an OAuth app. The owner says org and enterprise logs showed nothing, which is exactly what you would see if access came through a path those logs do not cover.
- A GitHub authorization bug. This is what the replies assume. It cannot be excluded, but it is the claim that needs the most evidence, and it needs GitHub to confirm.
What to do in your own organization
- Turn off member repo deletion. In organization settings, under repository policies, restrict who can delete or transfer repositories to owners only.
- Audit outside collaborators. List them with the GitHub UI or
gh api orgs/ORG/outside_collaborators, and remove any you do not recognize or no longer need. - Review token scopes. Find OAuth apps and personal tokens with
delete_repoand revoke those that do not need it. Require SSO authorization and OAuth app approval policies. - Stream the audit log. Alert on
repo.destroy,repo.transferandrepo.accessevents instead of reading them after the fact. - Keep a mirror. A scheduled
git clone --mirrorto storage you control is the only restore path that does not depend on GitHub's window. - Contact GitHub support immediately if a repo disappears, with the repo ID and timestamp.
Why this matters for people running coding agents
Even if this turns out to be human error, the failure pattern is one agents amplify. An agent that shells out to gh uses whatever your login can do. If you added delete_repo once for a cleanup and left it, every agent session on that machine can delete repositories. Our posts on monitoring versus blocking agent actions and the AI agent security incidents timeline cover how to limit that, and Aokigahara shows why long-lived tokens are the real prize.
How Beam handles this
Beam runs on a developer machine. It watches what Claude Code, Codex and similar agents do and flags risky actions such as destructive commands and credential exposure. In enforce mode, Claude Code and Codex PreToolUse hooks can deny a command like gh repo delete; other harnesses currently get a note only, and a missing cached policy is fail-open. That is a hook-based control, not a sandbox.
Beam cannot see or stop a deletion made from another machine, through a stolen token, or inside GitHub. For those, use the organization settings above. See how Beam is built.
What we are watching
- A statement from GitHub on whether the access path was a bug or a configuration.
- Whether the affected owners publish the repository access history they say shows nothing.
- Whether the other reports come with logs, and whether they share an access path.
We will update this post. The incident is tracked in the October 2026 attacks timeline.
Related reading
- Aokigahara infostealer and agent credentials
- AI agent security: monitor vs block
- AI agent security incidents timeline
- Mythos 5 and a malicious GitHub pull request
- October 2026 attacks timeline
Primary sources: International Cyber Digest on X · GitHub docs: organization repository permissions
Accurate as of October 28, 2026. This is an unconfirmed claim based on a partly redacted screenshot; we have not seen GitHub's response.