How to Connect Devin AI to GitHub

Devin AI's GitHub App asks for nine read-only permission scopes and eight read-and-write scopes before it can push branches, open pull requests, or reply on review threads [Cognition Devin Docs]. That is a full contributor footprint, not a read-only "chat about code" connection. Teams that treat the install like a casual OAuth popup usually under-scope repositories, skip branch protection, or never index the code, then wonder why pull requests look thin or Ask Devin answers miss half the tree.

Devin AI's GitHub integration connects Devin to your repositories so it can index code, open pull requests, and work inside existing GitHub engineering workflows. On GitHub.com, Cognition ships a managed GitHub App. On GitHub Enterprise Server and GitHub Enterprise Cloud with Data Residency, official docs document a dedicated GitHub App path (recommended when available) and a fine-grained personal access token path for broader GHES versions.

Once connected, Devin can:

• Clone and contribute to repositories you grant
• Open pull requests and respond to PR comments while the session is active
• Read Actions, checks, and related CI signals so it can reason about failing pipelines
• Index selected branches for Ask Devin and DeepWiki (indexing is a separate step)

Devin does not create new repositories in your GitHub account, and it does not mirror the personal permissions of whoever started the session. Access comes from the org-level install. Every user who is a member of both the GitHub org and the Devin org shares that same integration surface.

The setup sequence that ranks well and matches how the product actually works is simple:

1. Connect the GitHub App (or enterprise equivalent)
2. Choose which repositories Devin may touch
3. Index the branches you care about
4. Run a session that ends in a pull request
5. Review, comment, and merge under your normal branch rules

You must be an admin of the GitHub organization to create and manage the Devin integration. Individual developers without org-admin rights will hit the wall at authorization.

Install steps

1. Open app.devin.ai, then go to Settings → Integrations → GitHub.
2. Click Add Connection and complete GitHub authentication if prompted.
3. Select the GitHub organization to attach.
4. Choose All repositories or Select repositories. Prefer a curated set for the first rollout.
5. Finish authorization. Confirm the connection shows as active in Devin settings.

Core and Teams users can then @mention repositories in Devin prompts. Enterprise users can also delegate repositories to specific Devin sub-organizations from Enterprise Settings → Repository Permissions.

Permissions you should expect to review

Read access includes dependabot alerts, actions, deployments, metadata, packages, pages, repository security advisories, members, and webhooks. Read-and-write access covers checks, commit statuses, contents, discussions, issues, pull requests, projects, and workflows. Those scopes exist so Devin can act like a teammate: push code, open PRs, open issues, and inspect whether its changes pass CI.

After install, you can retighten access without redoing the whole dance:

1. GitHub org Settings → GitHub Apps (or https://github.com/organizations/<org_name>/settings/installations)
2. Configure on the Devin.ai integration
3. Under Repository access, switch between all repos and an explicit list
4. Save

Security defaults worth setting on day one

• Branch protection on the default branch. Cognition's docs recommend requiring checks before merge so Devin cannot land changes that fail your pipeline.
• Least-privilege repo selection. Start with one or two active product repos, not every fork and archive in the org.
• IP allowlisting when your GitHub policy requires it. Official docs list static outbound addresses including 100.20.50.251, 44.238.19.62, 52.10.84.81, 52.183.72.253, 20.172.46.235, 52.159.232.99, 4.204.199.103, 54.201.200.193, 54.69.238.189, and 100.23.34.160. Monitor Cognition release notes because the list can change.
• Wrong-org recovery. If the GitHub org is already bound to a Devin org you cannot access, a GitHub admin can uninstall Devin.ai Integration from GitHub settings, then reinstall under the correct Devin org after confirming with the previous owner.

Personal GitHub accounts can connect, but for team work connect the org that owns the repos your engineers actually ship from.

Connecting the GitHub App is not the same as giving Devin long-lived code understanding. Official indexing docs are explicit: repository indexing is separate from environment configuration. Indexing powers code search and understanding features. Environment configuration sets up the machine Devin develops on.

Without indexing, you can still run sessions against a connected repo, but you miss the DeepWiki-quality context layer that Ask Devin and DeepWiki rely on. Indexing is the prerequisite for those products to answer from your tree instead of guessing from the prompt alone.

How to index a repo

1. Sign in at app.devin.ai under the right organization.
2. Open Settings → Repositories.
3. Click Index repo on the connected repository.
4. Select the branch or branches Devin should analyze.
5. Wait for completion. Large monorepos take longer.

To add more branches later, open Manage on an indexed repo, pick a branch, and click Add branch. Cognition recommends indexing the branches your team actually develops on so Ask Devin and DeepWiki stay current.

What indexing unlocks

Ask Devin: Questions about the codebase, plus scoping and planning help grounded in indexed code.

• DeepWiki: Auto-generated documentation for the repositories you indexed.

Indexing failure modes teams actually hit

• Repo connected but never indexed. Integration shows green; Ask Devin still feels blind.
• Wrong branch indexed. You indexed main while all active work lives on develop.
• Stale branch set. Feature work moved; DeepWiki still describes last quarter's module layout.
• Environment setup skipped for first use. Indexing helps understanding, but Cognition still recommends completing development environment onboarding when you first work a repo so install, build, and test commands match reality.
• Enterprise delegation missing. On Enterprise, repos may need assignment under repository permissions before a given Devin sub-org can use them.

Treat indexing as an ongoing hygiene task, not a one-time checkbox. When a major package lands or the default branch renames, re-check the indexed branch list.

Keep Devin PR artifacts in one shared workspace

Use Fast.io for the specs, reports, and handoffs that should not live in git, with Intelligence Mode search and MCP access for agents. Every org starts with a 14-day free trial.

Start 14-Day Trial

Yes, Devin can open pull requests. That is a primary write path for the integration: contents and pull requests both require read-and-write access. Devin also automatically responds to PR comments as long as the session has not been archived. Archive the session and the comment loop stops.

Template discovery order

When Devin creates or regenerates a PR description, it searches the repository for the first matching template file. Official template docs list a long ordered path set. The practical takeaway for teams:

1. Prefer a Devin-specific file so humans keep their normal template.
2. Common Devin-only paths include .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md and .github/PULL_REQUEST_TEMPLATE/DEVIN_PR_TEMPLATE.md (plus docs/ and root PULL_REQUEST_TEMPLATE/ variants).
3. If no Devin-specific file exists, Devin falls through to standard pull_request_template.md locations.
4. If nothing matches, Devin uses a built-in default with Summary, Review & Testing Checklist, an optional Mermaid diagram, and Notes.

Minimal setup for a Devin-only template:

mkdir -p .github/PULL_REQUEST_TEMPLATE
cat > .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md <<'EOF'
### Summary

### Risk and rollout

### Test plan - [ ] Unit tests
- [ ] Manual QA steps
- [ ] Feature flag / config notes
EOF

That file lets you ask Devin for extra structure (risk notes, file diagrams, reviewer checklists) without changing the template human authors see in the GitHub UI.

Commit signing caveats

If you need Verified commits, configure GPG material in the environment/blueprint layer so it survives session restarts. Keys generated inside a live session terminal disappear when the session ends because each session boots from a fresh machine image. Cognition also notes that signing only produces Verified commits when Devin is the commit author under supported authoring modes (for example "Devin only" or "Devin as author, user as committer"). Modes that set the human as author can break verification against a single shared GPG key.

Practical review workflow

1. Start a focused session with an @-mentioned repo and a clear acceptance bar (tests to run, files in scope, out-of-scope areas).
2. Require Devin to open a PR rather than merge.
3. Use normal review comments; keep the session active while you iterate.
4. Rely on branch protection and required checks, not on trusting the agent to self-merge cleanly.
5. Archive only after the PR is merged or abandoned so stray comments do not expect a dead session.

Does Devin work with GitHub Enterprise? Yes. Official enterprise docs cover GitHub Enterprise Server (GHES) and GitHub Enterprise Cloud with Data Residency. Two connection methods exist.

Method A: GitHub App (recommended when available)

Cognition documents a three-step App flow. Availability may be limited; contact your Cognition representative if the App path is not enabled for your tenant.

1. Register the App once per GHES/GHEC instance from Devin Enterprise Settings → Integrations → GitHub → Advanced → Register App. Supply hostname and the org that will own the App registration.
2. Configure the App on the instance: make it public under Advanced so other orgs on the instance can install it, and opt out of user-to-server token expiration under Optional features so tokens do not force periodic re-auth thrash.
3. Install the App per organization from the same Advanced section. Choose orgs and repositories on the GitHub side. Repeat install for each additional GitHub organization.

Prerequisites include a Devin user with Manage git permissions and GitHub owner/admin rights on the registration org.

Method B: Fine-grained personal access token

Use this when App registration is not available or when you need a path that works across GHES versions.

1. Create a dedicated service account for Devin and add it as a Member to the relevant GitHub organizations.
2. Generate a fine-grained PAT as that user under Developer settings.
3. Grant at least Contents (read/write), Issues (read/write), Metadata (read), and Pull requests (read/write).
4. Set an expiration you can operationalize. When the token expires, Devin loses GitHub access immediately.
5. Validate locally before handing the token to Cognition: authenticate, push a throwaway branch, open a test PR, then close and delete it.
6. Finish setup with your Cognition contact or enterprise@cognition.ai if you are not already working with the team.

If the target org does not appear under Resource owner, fine-grained PATs may be disabled at enterprise policy, organization policy, or both. Enable them in Enterprise Policies → Personal access tokens and in the org's PAT settings before retrying.

Enterprise behavioral notes that differ from casual SaaS mental models

• Devin keeps org-level permissions; it does not temporarily shrink to the human who clicked "start session."
• After connect, configure which Devin sub-organizations may use each repository via enterprise repository permissions.
• First use of a repository still benefits from development environment onboarding so build and test commands match your monorepo reality.

GitHub remains the system of record for source, reviews, and CI. That is the right default for code. It is the wrong default for everything else an autonomous coding agent produces: design notes, run reports, acceptance matrices, customer redlines, export dumps, and intermediate analysis files that should not pollute main.

Teams usually try one of three holding patterns first:

• Local disks and laptops, which vanish when the person is offline and cannot be shared with the agent that needs them next sprint.
• Object storage such as S3 or GCS, which scales but leaves discovery, permissions, and human review as DIY work.
• General drives such as Google Drive or Dropbox, which humans know but agents treat poorly without a structured API surface.

Fast.io workspaces sit beside that stack as the shared place for agent and human file work outside the git tree. Enable Intelligence Mode so uploads are indexed for semantic search and citation-backed chat. Humans use the UI; agents use the Fast.io API or the MCP server over Streamable HTTP at /mcp (legacy SSE at /sse). Per-file version history keeps concurrent agent writes auditable. Ownership transfer lets an agent assemble an org and hand it to a human while retaining admin. Plans start with a 14-day free trial (credit card required) on Starter ($29/mo), Business ($99/mo), or Growth ($299/mo).

A practical split that works in production-shaped teams:

Devin remains the coding agent on the GitHub side. Fast.io is not a built-in Devin integration; it is the workspace layer for the files and handoffs that surround the PR. If you want a deeper product overview of that layer, start at /product/ai/ and /storage-for-agents/.