What happens to a developer's forks and local copies after removal?

When you remove someone from a GitHub organization, they lose access to private forks of your private repositories, but they may keep local clones. Those clones cannot sync with your repositories. Forks that live under other organizations are controlled by those organizations. Plan for retrieval, deletion attestations and secret rotation, not just removal.

What GitHub documents

GitHub's page on removing a member lists the practical effects:

• The member loses access to private forks of your organization's private repositories, and may still hold local copies.
• They cannot sync those copies with your repositories.
• If a private repository was forked into another organization, that organization controls the fork, so the person may retain access through it.
• Access to private forks of internal repositories is lost too, unless the person belongs to another organization in the same enterprise account.
• Invitations they sent are cancelled.
• Membership data is saved for three months, so a re-invite inside that window can restore their data and private forks they owned.

The same page says you are responsible for making sure that people who lost access delete confidential information and intellectual property. In other words, removal is a control over the live service, not over data already copied.

The gap to close

A local clone holds full history. That can include old commits with credentials, internal URLs, customer names in test fixtures and design notes in comments. Deleting the secret in a later commit does not remove it from history.

So the real question is not "can they still push?" It is "what is in the history they hold, and does any of it still work?"

A practical process

1. Before the last day, list repositories the person could read. Group them by sensitivity.
2. Check whether any of those repositories were forked into other organizations or personal accounts. Fork networks and the audit log help here.
3. Ask the person, in writing, to delete local copies and any personal forks of company code. GitHub points to a "prepare for job change" style checklist you can share. Keep the acknowledgment.
4. Rotate anything that was ever readable in history: tokens, keys, passwords, signing keys. Assume copied.
5. Review the repository for secrets in history using whatever tooling you already have. Safeguard does not offer secret scanning, so use a dedicated tool for that part.
6. If the person is returning, for example a contractor on a break, note the three month restore window and decide whether to let the old state come back or start clean.
7. Log what you did and when.

What a deletion request can and cannot do

Be honest about limits. A written request creates an obligation and a record. It does not prove deletion. For higher risk roles, pair it with device return and wipe, covered in your laptop offboarding process, and with rotation so a retained copy has little value.

Contractors and personal machines

If someone worked from a personal device, the fork and clone question is harder. Agree at the start of the engagement how code is stored, and prefer remote development environments where the code never lands on a personal disk.

Quick check

Safeguard's dependency scanning and policies help you see what your repositories pull in and enforce rules on pull requests. You can run a free scan at gold.safeguard.sh/scan.

Sources

• GitHub Docs: Removing a member from your organization

Last reviewed: 19 October 2026.