AI coding tools increasingly integrate directly with GitHub.
RepoRelay: Give ChatGPT access to your local repo — not your machine.
GitHub: https://github.com/Lukie-81/RepoRelay
For many workflows, that's enough.
But there's an important difference:
The code on GitHub isn't always the code on your computer.
The Working Tree Is Often What You Actually Want Reviewed
Imagine you're halfway through implementing a feature.
On GitHub, you might have:
- Your last stable commit
- Your current
mainbranch - Whatever you've already pushed
But locally, you might have:
- Modified source files
- New tests
- Untracked files
- A half-finished refactor
- Changes you aren't ready to commit yet
Now suppose you want to ask an AI:
Does this implementation make sense before I commit it?
A GitHub integration may not be able to see the code you actually want reviewed.
You could create a temporary branch and push everything:
Edit → Commit → Push → Review → Fix → Commit again
That works.
But for quick code review, it adds friction to something that should be simple.
The Other Extreme: Giving the AI Too Much Access
Another solution is giving an AI coding agent direct filesystem or shell access.
That solves the visibility problem — but it creates another one.
If the task is simply:
Read these files and review my code.
Why does the AI need permission to:
- Execute arbitrary commands?
- Access unrelated directories?
- Modify files anywhere on the machine?
- Run Git commands?
- Launch other processes?
For a reviewer, the useful capabilities are much narrower:
- List files
- Read files
- Search file contents
This suggests a simple principle:
The tool surface should match the task surface.
A code reviewer and an implementation agent don't necessarily need the same permissions.
A Narrower Approach
This is the idea behind an open-source project I've been building called RepoRelay.
Instead of exposing the entire computer, RepoRelay exposes one explicitly approved local repository through MCP.
The architecture is roughly:
ChatGPT Web → Secure MCP Tunnel → RepoRelay → Approved Local Repository
By default, RepoRelay provides a deliberately small tool surface for inspecting that repository.
It does not provide:
- A general-purpose shell
- Arbitrary filesystem access
- Git execution
- Access outside the approved repository root
Sensitive files are also blocked instead of being blindly exposed to the model.
The objective isn't to make an AI agent less capable.
It's to give it only the capabilities required for the job.
Local Access Solves a Different Problem
A GitHub integration essentially answers:
What code exists in this remote repository?
Local repository access answers:
What does my project look like right now?
That distinction matters.
A lot of software development happens in the space between editing code and committing code.
And that unfinished working tree is often exactly what you want reviewed.
Not All AI Permissions Are Equal
I think AI development tools will increasingly need to distinguish between different levels of access.
For example:
- Remote repository access
- Bounded local read access
- Bounded local write access
- Shell and process execution
- Full agent environment
Those permissions shouldn't automatically be treated as equivalent.
If an AI is reviewing code, bounded read access may be enough.
If it's implementing an entire feature autonomously, broader permissions may make sense.
The important part is making that decision deliberately.
Least Privilege for AI Coding Tools
As coding agents become more capable, the question shouldn't always be:
How much access can we give the AI?
A better question is:
What's the minimum access required for this task?
That's the trade-off I'm exploring with RepoRelay: giving an AI enough context to be genuinely useful without automatically giving it everything the machine can do.
RepoRelay is open source, so if you're interested in the idea — or want to criticize the security model — the implementation is available here:
GitHub: Lukie-81/RepoRelay
I'd be interested in hearing how others think about permission boundaries for AI coding tools.
Top comments (0)