Sazabi and GitHub: trace errors to code, open fix PRs, review pull requests
Last verified on Nov 8, 2026.
When an error reaches production, the next question is nearly always "what code is this?" Sazabi is AI-native observability and security, and its GitHub integration puts your repositories in the agent's reach, so a stack trace can be read next to the source that produced it.
GitHub is a forge integration. It is one of the broader pages here, because three separate connection methods exist and each does a different job.
What the Sazabi agent can do with GitHub
Core integration (the Sazabi GitHub App). You install the app on the repositories you choose, then map them to a project. The agent searches and reads those repositories to trace an error to the exact file and line. It can correlate errors with recent changes and pull requests, and open a pull request with a proposed fix. The docs state that the pull request is ordinary, with a branch, a diff and a description, and that nothing merges automatically. Sazabi can also review new pull requests with inline comments and a verdict, which is a limited release with its own toggles. Mention @Sazabi in a pull request comment to ask a question, and the answer comes back in that thread.
The app asks for Contents (read and write), Pull requests (read and write) and Metadata (read). Three more read permissions are optional: Dependabot alerts, Code scanning alerts and Secret scanning alerts. Without one, the agent skips that source and the connection still shows connected.
Sandbox CLI. This puts the GitHub CLI, gh, in the agent's sandbox, authenticated with a GH_TOKEN you supply: a fine-grained token or an app installation token. It is separate from the app, which covers the code-search tools.
Manual log source. The GitHub Audit Log streams an Enterprise Cloud enterprise's audit events to Sazabi through GitHub's Splunk streaming target. Common fields become attributes such as github.audit.action, github.audit.actor and github.audit.repo.
What it helps with
- Which file and line produced this stack trace?
- What recent pull requests touched this code?
- Does a vulnerable dependency already have a Dependabot alert, and which version fixes it?
- Why did this test start failing, as asked in a pull request comment?
- Who changed repository visibility or a deploy key last week?
A worked example: a flagged package in a pull request thread
A reviewer notices a dependency bump and asks in the pull request, with the optional Dependabot permission granted. Names are invented.
Pull request #318 Bump image-resizer to 4.2.0
maria-dev @Sazabi summarize the risk in this change. Is image-resizer flagged?
Sazabi Reads the repository and its Dependabot alerts, then replies in this thread:
the manifest that pulls the package in, whether an alert is open, and the version that fixes it.Sazabi's docs describe exactly those three things for the optional permission: whether a vulnerable dependency already has a Dependabot alert, which manifest pulls it in, and which version fixes it. GitHub's REST documentation shows the matching fields on an alert, dependency.manifest_path and first_patched_version, and says reading them takes the "Dependabot alerts" repository permission (read). Sazabi's note is that the agent can only read alerts, never dismiss, reopen or comment on one, and the alert type must also be enabled on the repository in GitHub.
GitHub's app model explains why the list is short. GitHub Apps have no permissions by default and are meant to request the minimum. Sazabi's docs add that when the app gains an optional permission, GitHub asks your organization's owners to approve it, and nothing changes until an owner accepts.
How it fits with other integrations
Teams on Atlassian's forge use Bitbucket for the same code search and pull request flow. Tracker links go through Linear and Jira, and issue cards can post to Slack. More security-oriented sources are listed under security integrations, and every method is on the integrations index. See pricing for plans.
Ways to connect
- GitHub (core integration): Connect GitHub so the Sazabi agent can search your code during investigations, and optionally review new pull requests.
Log sources
- GitHub Audit Log (manual log source, security): Stream your GitHub Enterprise Cloud audit log, including Git events, to Sazabi through GitHub's Splunk audit log streaming target.
Frequently Asked Questions
Does Sazabi need write access to my repositories?
The Sazabi GitHub App asks for Contents and Pull requests with read and write, so the agent can push a branch and open a pull request, and Metadata with read. Nothing merges automatically; you review and merge as usual.
What are the three ways to connect GitHub?
The core GitHub App integration for code search and pull requests, a sandbox CLI that puts gh in the agent sandbox using a GH_TOKEN, and a manual log source for the GitHub Enterprise Cloud audit log. Each has its own setup and permissions.
Which security alerts can the agent see?
With the optional read permissions, Dependabot alerts, code scanning alerts and secret scanning alerts. The agent only reads them, and for secret scanning it sees the type, file and line, never the secret.
Why can't the agent find a file I know exists?
Code search is scoped to the repositories mapped to the project you are working in. Check that the repository is installed on GitHub and mapped to that project.
Sources
- Core integration: GitHub App, repositories mapped to a project, code search, agent-opened pull requests, optional review, @Sazabi in pull request comments, and the required and optional permissions (accessed Nov 8, 2026)
- Sandbox CLI: gh in the agent sandbox, authenticated with GH_TOKEN, separate from the GitHub App (accessed Nov 8, 2026)
- Manual log source: Enterprise Cloud audit log streamed through the Splunk target, with github.audit.* attributes (accessed Nov 8, 2026)
- Agent-opened pull requests never merge automatically; review and @Sazabi review are separate paths (accessed Nov 8, 2026)
- GitHub Apps have no permissions by default and should request the minimum; permissions are repository, organization, enterprise or account level (accessed Nov 8, 2026)
- Dependabot alerts expose the dependency manifest path and the first patched version, and are read with the Dependabot alerts repository permission (read) (accessed Nov 8, 2026)