Handing your codebase to someone is the part that makes founders hesitate — reasonably. The good news: you can give a reviewer everything they need to read your code and nothing they could use to change it, and you can revoke it the moment the review is done.
Here’s how to do it cleanly, and what to double-check while you’re in there.
The principle: read-only, scoped, revocable
A code review needs exactly one thing: the ability to read the repository. Not push, not merge, not manage settings, not touch secrets. So the goal is the narrowest grant that allows reading, on the smallest scope, that you can pull back later.
Never share a reviewer your account password, an admin invite, or write access. You don’t need to — and a serious reviewer will never ask for it.
GitHub
A few good options, easiest first:
- Read-only collaborator (private repo). Repo → Settings → Collaborators → Add people → set the role to Read. They can browse and clone; they can’t push. Remove them when you’re done. (On an org repo, add them to a team with the Read role instead.)
- Fine-grained personal access token (no collaborator needed). If you’d rather not add a person: Settings → Developer settings → Fine-grained tokens → scope it to the single repository, grant Contents: Read-only (and Metadata, which is required), set a short expiry. Share that token. It can read one repo and nothing else, and it dies on its own.
- A read-only deploy key. Repo → Settings → Deploy keys → add the reviewer’s public key, leave “Allow write access” unchecked. Scoped to that one repo, read-only, easy to delete.
Whichever you pick: it’s one repo, read-only, and you can revoke it in one click afterward.
GitLab
- Add the reviewer as a project member with the Reporter role. Project → Manage → Members → Invite. Reporter can view and clone code but cannot push or change settings. Remove them after.
- Or a project access token / deploy token with the
read_repositoryscope only, and an expiry date.
What “they can’t do” with read-only
To be concrete — with any of the above, the reviewer cannot: push commits, open or merge PRs/MRs on your behalf, change branch protection or settings, add other people, see organization-wide resources, or touch your deployment. They can read the code of the one repo you shared. That’s it.
Before you share: a 2-minute hygiene pass
Granting read access is safe. But while you’re looking, check the thing that isn’t:
- Secrets in the repo. If real API keys, database URLs, or tokens are committed (in a
.env, a config file, or the git history), anyone with read access can see them — and so could anyone who ever had it. Rotate any real secret that’s been committed, and move secrets to environment variables going forward. (This is also one of the most common findings in a review, so you may as well get ahead of it.) - Scope to one repo. Share only the repo being reviewed, not your whole org or account.
- Set an expiry / calendar a reminder to revoke access once the report is delivered.
After the review
Remove the collaborator, delete the token, or remove the deploy key. Read access leaves no trace in your code and changes nothing — pulling it back is instant.
This is exactly how a seniorgrade audit works: read-only access, nothing else. We can’t change, push, or delete anything; your code is read for the review only, never executed, and deleted from our side once the report is delivered. If you’ve been holding off on a review because sharing the code felt risky — this is the safe way to do it. Get your audit →