What happens to a contractor's local clone when you remove them?

Nothing happens to it. Removing a contractor stops them pulling or pushing, and deletes their forks of your private repositories, but whatever is already on their machine stays there. Plan for that with a written deletion step, limited scope up front, and rotation of anything the clone contained.

What GitHub says is removed

GitHub's documentation on removing an outside collaborator says that forks of private repositories are deleted when the collaborator is removed, but the person still keeps any local clones. It adds that you are responsible for ensuring people who lost access delete confidential information or intellectual property.

For organization members, the guidance is the same in substance: removed members lose access to private forks of your private repositories, may still have local copies, and cannot sync those copies with your organization's repositories.

There is one more wrinkle. If a private repository was forked into another organization, that organization controls access to its fork network, so a person can keep access to a fork even after losing access to the original.

What remains after removal

What you can do about it

You cannot reach into a contractor's laptop, and you should not try. You can reduce exposure in four ways.

1. Limit what they cloned in the first place. Give access to one repository, not a whole organization. A monorepo with many teams' code is a bigger leak than a service repository.
2. Keep secrets out of the repository history. A clone contains every commit, including ones you thought you deleted. If a credential was ever committed, rotate it as if it left the building.
3. Rotate on exit. Rotate tokens, keys and shared passwords the contractor could have seen. Prioritize anything with production reach.
4. Get a written deletion statement. Ask the contractor, or the agency, to delete local copies and confirm in writing, including backups and personal cloud sync folders. Treat this as an administrative record, not a guarantee.

Put it in the contract before it matters

Your statement of work should say where code may be stored (company issued or managed devices only, or a named remote environment), that personal machines and personal cloud storage are off limits for source code, and that deletion at exit is confirmed in writing. Have your legal advisers word the contract. From an engineering side, the useful part is making the rule easy to follow, for example by providing a managed development environment so there is nothing local to delete.

Reduce the problem structurally

• Prefer short lived work areas. A contractor who works in a hosted workspace you control leaves nothing on a personal disk.
• Use read only clones for reviewers who do not need to run code.
• Split the repository so a contractor sees the module they are working on, not the whole product.

After removal, verify

Check the audit log for the contractor's actions near the end of the engagement, confirm that their invitations and tokens are gone, and note the date. The contractor offboarding checklist lists the other accounts to close, and deploy keys and contractor offboarding covers the key that outlives the person.

Safeguard's dependency scanning and SBOM generation can show what a repository contained at the time a contractor held access, which helps you decide what needs rotating or reviewing. Try the free scan.

Quick check

Sources

• Removing an outside collaborator from an organization repository
• Removing a member from your organization

Last reviewed: 19 October 2026.