What Modulo Does With GitHub

GitHub is where most Modulo teams keep their code, so the GitHub integration is the one they meet first. It is an API client with the token you provide, pulling work in and pushing results back under the rules GitHub already enforces.

Connect with a token you control

A GitHub connector instance holds a token, an owner, a repository, and a base branch. Fine-grained personal access tokens are supported, and the connector reports which scopes a token actually holds so a missing permission surfaces as a health check rather than a failed run. The required scopes are contents:read, contents:write, and pull_requests:write. See Connectors and Secrets for how the token is encrypted at rest.

What it reads and writes

Reads cover the repository files and tree, pull requests and their diffs, branches, issues, and repository search.

Writes cover files and commits (batched through the Git Database API so a multi-file change lands as one commit), issues and their comments, labels, milestones, and the pull request lifecycle: create, update, review, comment, request review, label, and merge.

That means an agent can open a pull request, respond to review with a reply comment, and apply a label, all inside the governed run.

Trigger GitHub Actions, read the result

A separate CI-runner connector triggers and observes GitHub Actions: start a workflow, read its status, read its logs, and list runs. Wiring a pipeline node to dispatch to Actions is in development. See Triggers for how a pipeline starts and chains.

GitHub's rules stay in charge

Modulo writes through the GitHub API, so branch protection, required reviewers, and CODEOWNERS still decide what reaches a protected branch. A Modulo gate that approves an agent's output adds an approval to the chain; it does not bypass the rules GitHub enforces on the branch itself.

Every GitHub action an agent takes is a node in a pipeline, so it gets the same treatment as any other step: input and output schema checks where a schema is declared, the same gate, and the same audit event. The run detail links the pull request back to the run that produced it.

GitHub's new native surfaces

GitHub has spent 2026 absorbing agent infrastructure into itself. Agentic Workflows (public preview 11 June 2026) let a team define programmable agent workflows in Markdown and run them through GitHub Actions, with a sandbox, an Agent Workflow Firewall, and a safe-outputs gate. Copilot code review became callable over the REST API on 2 October 2026, and local sandboxing for Copilot sessions went generally available on 7 October 2026, restricting filesystem, network, and credential access to policy the developer or their organization defines.

Those are containment and orchestration improvements, and they are good ones, and they still answer the inside-GitHub question. A sandbox bounds the agent while it runs; it does not record what shipped, who approved it, or what the change did in the tracker two systems away. A change that starts in Linear and ends in a merge on GitHub still leaves its record spread across both, and re-checking it means going back to GitHub. The cross-tool, offline-verifiable version of that record is what Modulo keeps - see Modulo vs GitHub native agent governance.

Where to go next

• Modulo vs GitHub native agent governance: the inside-vs-across comparison
• Connect a tool: connector configuration
• Govern Coding Agents Across Teams: multi-repo, multi-team policy