The problem: your AI coding assistant doesn't know what's already in the repo
Working with an AI client inside a codebase, you run into the same wall over and over: it can reason well about the file that's open right now, but it has no idea what issue you're actually fixing, what a related pull request already tried, or what the last few commits changed. You end up pasting in issue text, summarizing PR discussion by hand, or just working without that context and hoping nothing important got missed.
It's worse across projects. A generic connection that doesn't know which repository it's working in mixes context from one codebase into an unrelated one, which is often worse than having no shared context at all. What's actually needed is a connection that knows which repo it's for, and pulls in the parts of GitHub — issues, PRs, commits — that give an AI client real project awareness instead of just code-in-front-of-it awareness.
This guide covers connecting GitHub so that context is available, and how the workspace it lands in stays scoped to the right repository automatically.
How it works
GitHub connects to your account as an integration, scoped to the specific repositories you choose rather than your whole GitHub account — the same per-workspace resource scoping used for other integrations. The issues/PRs/commits sync is tied to a repository's own workspace rather than firing generically the moment you authorize GitHub: when a repository's REPO workspace is provisioned and your GitHub integration already covers that repo, the integration is linked to that workspace and a scoped initial sync pulls the repo's issues, pull requests, and commits in, so they're searchable the same way any other stored memory is.
Separately, workspaces themselves have a kind, and REPO is one of them — built specifically for this case. A REPO workspace auto-provisions from the repository's own URL: when a connecting client sends an X-Repo-URL header (this is how a coding agent working inside a repo identifies it), or the connection is set up via the CLI's gad-init.sh script, the server creates or reuses a workspace bound to that exact repository. Work tied to one repo lands in that repo's own workspace; a different repo gets a different one, so GitHub context from one project doesn't bleed into another.
The first time a REPO workspace gets created, the connecting agent is prompted to seed a bounded starting snapshot — the README, the project's file structure, key manifest files, and recent git log — into memory, so a brand-new project workspace isn't empty on day one, even before the GitHub sync has pulled anything in.
Setting it up
- Create your account. Sign up at /sign-up — no credit card required for the 14-day trial.
- Connect GitHub from your integration settings. Authorize the connection and choose which repositories to scope it to — you don't have to connect your entire account.
- Connect an AI client from inside the repo you're working in. Go to /install and connect a coding-oriented client — Cursor, Claude Code, or another supported option — from a terminal or editor session opened in that repository, so the connection can identify the repo. This is what provisions the repo's own REPO workspace, and — because your GitHub integration already covers the repo — links the integration to that workspace and kicks off the scoped initial sync of its issues, pull requests, and commits.
- Let the first-connect prompt run, if it's a brand-new repo. The connecting agent may seed an initial snapshot into memory automatically as part of the conversation — no separate manual step.
- Test it. Ask the connected client about a specific issue, PR, or recent commit in the repo, and confirm the answer reflects real GitHub content.
What this gives an AI client day to day
Once GitHub is connected and a repo's REPO workspace exists, asking a connected client about the current project pulls from that repo's own synced issues, PRs, and commits — not a generic pool mixed with every repo you've ever connected. Switching to a different repository switches which workspace the client is reading from and writing to, the same automatic scoping REPO workspaces provide for any memory stored while working in that repo.
GitHub access isn't read-only. Beyond searching synced issues, PRs, and commits, a connected client can take action when you ask it to — creating issues, opening pull requests, leaving reviews, merging PRs, and dispatching GitHub Actions workflows. Reading and acting are separate capabilities in practice: connecting GitHub makes both available, but nothing gets created or merged unless you actually ask a client to do it.
One connection, every client
The GitHub context that syncs into a repo's workspace isn't reserved for the coding tool that provisioned it. The workspace is part of the same account-level memory every connected client reads, so the issues and PR history a Cursor session pulled in are just as searchable from Claude, ChatGPT, or a Gemini CLI session connected to the same account — useful when the person asking "what's the status of that bug" isn't sitting in an editor at all. Memories and integration credentials are encrypted at rest with AES-256-GCM, and uploaded files live in encrypted storage; Postgres row-level security isolates each workspace at the database layer, so per-repo scoping is enforced in the database, not just in the UI.
The same goes for GitLab users, incidentally — GitLab is a separately connectable integration with its own project management capabilities, and REPO workspaces themselves are provider-agnostic: the workspace keys off the repository URL a connecting client reports, so the per-repo scoping mechanics described here don't depend on GitHub being the host.
Where to go next
For the deeper walkthrough of what a connected client can do with GitHub specifically, see Gemini MCP Server for GitHub. If you're also connecting an editor like Cursor and want the REPO-workspace mechanics explained in full, Give Cursor Persistent, Project-Aware Memory covers that in depth.