What "connect" means
You have repositories. Some of them are noisy projects that nobody wants AI touching this quarter. Others are the ones where you'd like Ship to actually do work — read the code, comment on pull requests, run routines, mirror the standing rules. Connecting a repo is how you draw that line. Ship sees only the repos you've connected, acts only on the repos you've connected, and goes anywhere near nothing else.
The connection is reversible. You can disconnect a repo and Ship goes inert on it the same hour. Nothing in the repo itself gets damaged when you disconnect — the code, the issues, the actions all stay where they are. Ship simply stops watching.
The two-step shape
Connecting happens in two steps and we keep them separate on purpose.
Step one is install. You add the Ship app to your GitHub organization or your personal GitHub account. This is the standard install flow GitHub already runs for any app: a permissions screen lists what Ship is allowed to read and write, and you approve it. If you're the org admin you approve it yourself. If you're not, GitHub forwards the request to whoever is, and you wait for them. There's no way around this step; that's GitHub's security model, not ours.
Step two is activate. Once the app is installed, every repo in that org becomes visible to Ship in a list. None of them are active yet. You go through the list and check the boxes for the repos you actually want under Ship — usually one or two to start, more as you get comfortable. Repos you didn't check stay visible for reference but Ship never touches them.
We keep the steps separate because they answer different questions. Install asks: can Ship see anything in this org at all? Activate asks: which specific repos is Ship allowed to act on? Most teams want a broad install scope (so they can add a repo later without re-asking the security officer) and a narrow activation scope (so the AI only touches what they've thought about).
What happens when you activate
A .ship/ folder shows up in the repo as a pull request for your team to review. It holds the rules Ship will read for that repo — which routines run, which states unlock which actions, where the standing rules live. You can edit those files like any other code, or refuse the PR and the repo simply doesn't get activated.
The workspace home starts showing the repo on the dashboard: last deployment, open pull requests Ship has touched, routines that have run. And routines you've defined can now target this repo — a daily security review, a stale-issue sweep, a developer routine that picks one ready ticket per morning.
What Ship can and can't do on a connected repo
Inside a connected repo, Ship can comment on pull requests, read code, read issues, and write the standing rule mirror. Ship cannot push directly to your default branch. Every change AI makes lands as a pull request your team reviews like any other.
Ship cannot reach a repo you haven't activated, cannot reach an org you haven't installed in, cannot see your personal GitHub inbox or your other workspaces. Those boundaries are enforced by GitHub, not by us — they're the same boundaries any GitHub app lives inside.
Pause and disconnect
If you want Ship to stop on one repo without removing the install, you deactivate it from the repos page. It goes inert: no comments, no routines, no mirror. The audit log keeps the history of what Ship did there before, in case you need it later.
If you want Ship out of the org entirely, you uninstall from GitHub. That removes Ship's access everywhere in that org and all the activated repos in it go quiet at once.
The next page walks the tracker binding.