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.
Imagine you're halfway through implementing a feature.
On GitHub, you might have:
main
branchBut locally, you might have:
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.
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:
For a reviewer, the useful capabilities are much narrower: 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.
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:
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.
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.
I think AI development tools will increasingly need to distinguish between different levels of access.
For example: 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.
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.