Two valid sources of truth

GitHub access and local access solve different problems.

GitHub is often the right place for AI-assisted code review: it is shareable, versioned, and already part of a collaborative workflow. RepoRelay is for the case where you specifically want ChatGPT to inspect one approved repository on the machine in front of you.

Last updated: August 23, 2026

Answer first

Why use RepoRelay instead of pushing code to GitHub?

Use RepoRelay when the review target is an uncommitted working tree or local project state that you are not ready to publish. It gives ChatGPT bounded access to one approved directory through an MCP server you run locally.

Use GitHub when the reviewed state should be a branch, commit, pull request, issue, or durable collaborative link. Neither workflow is automatically safer: each has a different source of truth, permission model, and operator responsibility.

See how ChatGPT local repository access works, read how local files can be reviewed without a ZIP upload, or read the RepoRelay security model before choosing.

At a glance

Choose the source that matches the work.

Question	GitHub-based access	RepoRelay local access
Where does the reviewer read?	Code stored or pushed to a GitHub repository.	One explicitly approved local repository directory.
What state is visible?	The selected branch, commit, issue, pull request, or other GitHub surface.	The current local working tree that RepoRelay is started against.
What must happen first?	Code must be available on GitHub and the integration must have the appropriate access.	RepoRelay must be installed, started, audited, and reachable through the chosen MCP connection.
What is the main boundary?	GitHub repository permissions and the AI integration's granted scope.	RepoRelay's loopback/authentication, one-root containment, sensitive-path, and tool-surface checks, plus the external tunnel's controls.
Can the reviewer use a shell?	That depends on the integration; GitHub access alone is not a shell.	RepoRelay exposes no shell, PowerShell, Git, process, or arbitrary mutation tools.

Use GitHub when...

GitHub is already the project's source of truth.
You want a review tied to a branch, commit, pull request, or issue.
The code is ready to share through your existing repository permissions.
Collaborators need a durable, versioned link to the reviewed state.

There is no need to add a local bridge when GitHub already provides the workflow you want.

Use RepoRelay when...

The work is still local and not pushed yet.
You want to review the current working state before deciding what to publish.
You have local project files that are intentionally allowed by RepoRelay's path policy.
You want ChatGPT Web alongside a local coding agent without uploading a ZIP or granting general computer control.

Local access still requires judgment: do not approve a repository containing credentials the reviewer should not receive.

A practical workflow

You can use both, at different moments.

A team might use RepoRelay to review a local change, let a local agent implement the bounded task, then push the resulting branch to GitHub for the normal collaborative review. Or it might use GitHub for everything and never run RepoRelay.

The decision is about which repository state the reviewer should see and which connectivity model your organization accepts. It is not a claim that one platform replaces the other.

Local rootCurrent work in progress.

RepoRelayBounded review and handoff.

Local agentImplementation under your control.

Git commitYour normal source-control step.

GitHubOptional shared source of truth.

Bottom line: Use GitHub when GitHub is the right source of truth. Use RepoRelay when you specifically want bounded access to an approved local repository. Review the security boundary before connecting either workflow.