GitHub is the connection to be most careful with. A Slack post can be embarrassing. A change to a pull request can ship. So the honest advice comes first: connect it, enable reads, and keep every write behind approval until you've watched it work for a few weeks.
It's an agent connection from the catalog, not a code tool. Agents call GitHub actions when you ask. They don't watch your repos in the background, and nothing from GitHub is copied into Nautis.
Who gets the most from it
A technical founder running a two-person team gets status answers without leaving the briefing, and can turn a customer email into an issue in one approval. A non-technical founder gets something rarer: a way to ask what changed this week without interrupting the person writing the code.
If your engineers plan in Linear and only keep code in GitHub, connect Linear for planning work and use GitHub mainly for reads.
Connect GitHub
- Open Integrations from your avatar menu. GitHub is in the featured row.
- Click Connect. GitHub shows the app's developer contact information and the specific data being requested. Read both.
- Approve. Nautis shows a GitHub connected toast and opens the tool's page.
- In the Allow agents to use GitHub? dialog, you can pick Not now. That's a sensible choice here, so you can review the actions first.
- Open Available actions. GitHub's actions are listed, each tagged Read or Write. Switch off every write you don't need, then turn on Agent access.
Why your GitHub organization may block the Nautis GitHub integration
If the connection is registered as an OAuth app, your organization's settings decide what it can reach. GitHub's page on OAuth app access restrictions says these restrictions are on by default for new organizations. While they're on, members can't authorize an OAuth app to reach organization resources, but they can ask an owner to approve it, and owners are notified.
Without restrictions, GitHub warns, any OAuth app a member authorizes can also reach the organization's private resources. That's an argument for keeping them on and approving apps one at a time.
GitHub's authorization guide adds two points worth knowing. A token can never exceed your own rights, so an app can't get owner powers from a member. And source code access can't currently be scoped to read-only.
Keep writes narrow on the Nautis side
Because GitHub's own permissions are broad, the useful limits live in Nautis. Here's a sensible starting setup. The exact action names come from GitHub and appear under Available actions.
| Kind of action | Read or write | Suggested setting at first | Default approval |
|---|---|---|---|
| Reading repos, issues and pull requests | Read | On | Runs without a prompt |
| Opening an issue | Write | On | Waits for approval |
| Commenting on an issue or pull request | Write | On, if your team wants it | Waits for approval |
| Changing, closing or merging pull requests, if listed | Write | Off | Waits for approval |
| Anything that deletes, if listed | Write | Off | A delete is a write here, not covered by Deleting always asks |
Don't set Connected app actions (Integrations) to Run without asking while GitHub writes are on. That setting has no per-tool version, so it would let every enabled GitHub write run unattended.
After two or three weeks, open AI Activity and look at what agents actually did in GitHub. If every write you approved was an issue, leave the rest switched off for good.
Workflows
The Friday investor update
Ask your Chief of Staff which pull requests merged this week. It reads GitHub and gives you a plain list to rewrite for investors. No approval needed, because nothing changed.
A bug from a customer email
A customer sends steps to reproduce a crash. Ask an agent to open a GitHub issue with them. Show details on the approval shows exactly what would be sent to GitHub before anything is created.
Sorting a backlog before planning
Before a planning session, ask for the open issues labelled as bugs in your main repository, grouped by how old they are. It's a read, so the answer arrives straight away, and you walk into the meeting with a list instead of a guess. If you want any of them closed or relabelled and those actions are listed, ask, and each change comes back as a card to approve.
Troubleshooting
- The agent can't see private repos. Your GitHub organization restricts app access. An organization owner needs to approve the app.
- Connected, but agents ignore GitHub. Agent access is off, or the action is switched off.
- Writes go to the wrong account. Agents act through the Primary account. Use Make primary to change it.
- Status says Expired. Click Reconnect and authorize again. Nothing else changes.
- You want to cut access fast. Click the trash icon on the account row. GitHub keeps its own list of authorized apps where you can revoke it too.
Limits
- No sync. Agents read GitHub when asked, and nothing is mirrored.
- Only owners and admins can connect or enable it, and the connection serves the whole organization.
- Not available from WhatsApp yet.
- Disconnecting deletes nothing in GitHub.
- Writes and approval decisions are logged in AI Activity, visible to owners and admins. See AI Governance.
FAQ
Can the Nautis GitHub integration merge pull requests on its own?
Only if GitHub exposes such an action, it's switched on, and an admin has set connected-app actions to Run without asking. By default every write waits for approval. The safer setup is to switch off any merge action entirely.
Does Nautis copy our code?
No. Nautis doesn't sync or copy data from connected tools. Agents call GitHub actions on demand, such as reading a repo when you ask about it.
Can I give agents read-only access to our repos?
GitHub says source code access can't currently be scoped to read-only on its side. In Nautis you can still switch off every write action under Available actions, so agents can only use the read actions.
Who approves the app in our GitHub organization?
Organization owners. When OAuth app access restrictions are on, members request approval and owners are notified to approve or deny it.