GitHub
GitHub App install, repo-project bindings, webhook routing, and workflow nodes.
The GitHub integration connects your organization to GitHub through the Rensei GitHub App - one connection that covers repositories, pull requests, CI status, and issues. There are no tokens to create or paste: you install the App on your GitHub account or organization, grant it access to the repositories you choose, and bind those repositories to Rensei projects.
There is a single GitHub card in Settings → Integrations. Issue-tracking capability is part of this same connection - see GitHub Issues (tracker) for using GitHub Issues as a project issue tracker.
What you can do
- Pull request management: create, comment on, and merge PRs from workflow nodes
- Branch and file operations: create branches, read file contents
- Issue tracking: create, update, label, assign, and comment on GitHub Issues (node reference)
- Webhook triggers: run workflows on push, PR opened/merged, PR review, check-run completion, issue assignment, and issue comments
- Repo-project bindings: route each repository's webhook events into the right project's workflows
- Agent actions: agents can commit code, open PRs, and respond to CI failures
Connect GitHub
Enable the integration (feature flag)
The GitHub integration is gated by a per-organization feature flag, integrations.github_issues_enabled (the name is historical - it now gates the whole unified GitHub integration). Ask your Rensei operator to enable it; without it the App install flow is rejected.
Install the Rensei GitHub App
- In Rensei, go to Settings → Integrations and find the GitHub card
- Click Configure (or Manage if already connected) to open the GitHub settings sub-page
- Click Install GitHub App
- You are redirected to GitHub's App installation page
- Select your organization (or personal account)
- Under Repository access, choose:
- All repositories - Rensei can access every repo on the account
- Only select repositories - restrict to specific repos
- Click Install to confirm
You are redirected back to Rensei with a confirmation banner. You control which repositories Rensei can access, and you can change the selection at any time from GitHub's App settings (use the Manage on GitHub link next to each installation).
Bind repositories to projects
On the same sub-page, the Installations panel lists each App installation. Expand an installation to see its repositories, then use Bind to project to wire a repo to a Rensei project.
Bindings are what route webhook events: a push or PR event on a bound repo dispatches workflows in the bound project. A repository with no binding triggers nothing. The Active bindings panel lists every wired repo with an Unbind action.
Webhooks need no manual setup. The GitHub App delivers events for all repositories it can access to a single platform endpoint (/api/webhook/github), verified with an App-level signing secret. There are no per-organization webhook URLs or secrets to configure.
Managing installations
The GitHub sub-page (Settings → Integrations → GitHub → Manage) also covers:
- Add another account - run the install flow again to connect an additional GitHub account or organization. An org can hold several installations.
- Available to add - installations of the Rensei GitHub App that exist on GitHub but are not yet connected to your workspace. Claim requests access (operator-gated); non-operators can use Add another account to install directly.
- Manage on GitHub - deep link to the installation's settings page on GitHub, where you adjust repository access or uninstall.
- Refresh - re-syncs installation and repository state from GitHub.
- Reinstall App - shown on the integration card when the health check fails; a broken App installation is repaired by reinstalling, not by re-entering credentials.
- Disconnect - removes your workspace's access to the installations. The App itself is uninstalled on GitHub only when no other workspace shares the installation.
Webhook events and routing
| Property | Value |
|---|---|
| Endpoint | POST /api/webhook/github (App-level, managed automatically) |
| Signature | HMAC-SHA256 on x-hub-signature-256, verified against the App's signing secret |
| Idempotency | Deliveries are deduplicated on GitHub's delivery ID; retries collapse to a no-op |
| Routing | Events fan out to every organization holding a live binding for the repository; events on unbound repos are recorded as unmatched |
The Webhook health panel on the GitHub sub-page shows 24-hour delivery metrics (received / routed / unmatched / errored) and recent failed deliveries, so you can confirm events are flowing without leaving Rensei.
Event filtering
Trigger nodes filter the event stream declaratively. For example, github.push can match on branch name and forced-push status, and PR triggers expose action and author fields for downstream conditions. See workflow triggers and the trigger node reference for output schemas.
Workflow nodes
GitHub nodes appear in the workflow editor's node palette once the integration is connected.
Triggers
| Node | Fires when |
|---|---|
github.push | Commits are pushed to a branch |
github.pr.opened | A pull request is opened |
github.pr.merged | A pull request is merged |
github.pr.review_submitted | A PR review is submitted |
github.check_run.completed | A check run completes |
github_issues.issue.assigned | A GitHub Issue is assigned |
github_issues.comment.created | A comment is posted on a GitHub Issue |
Actions
| Node | Description |
|---|---|
github.pr.create | Create a pull request |
github.pr.comment | Comment on a pull request |
github.pr.merge | Merge a pull request |
github.branch.create | Create a branch from a ref |
github.file.read | Read a file's contents from a repository |
github_issues.* | 13 issue lifecycle nodes: create, update, close, label, assign, comment, milestones |
issue.* | Tracker-agnostic issue nodes that route through the project's tracker binding |
Full input/output port references live on the node pages: GitHub action nodes, GitHub Issues action nodes, generic action nodes, and trigger nodes.
Authentication model
The integration is purely App-install based:
- No OAuth tokens or personal access tokens. API calls authenticate with short-lived installation tokens minted from the App installation.
- Access follows the installation. What Rensei can reach is exactly the repository set you granted during install (adjustable on GitHub at any time).
- Health checks mint an installation token periodically; a revoked or suspended installation marks the integration unhealthy and surfaces a Reinstall App action.
Rate limits
GitHub rate-limits API calls per App installation (5,000 requests/hour baseline). High-volume agent workflows dispatching many parallel work items can hit this limit; prefer caching repeated reads (for example, file contents) in workflow steps.
Troubleshooting
"GitHub App not installed"
Open Settings → Integrations → GitHub → Configure and click Install GitHub App. If you installed the App but still see this, check that the installation is connected to this workspace (it may appear under Available to add).
"Integration not enabled"
Your Rensei operator has not enabled the GitHub feature flag for this organization. Contact your admin.
"Permission denied" on repo operations
The App installation does not cover the target repository. Use Manage on GitHub to extend the installation's repository access.
Webhook events not arriving
Check the Webhook health panel on the GitHub sub-page. unmatched deliveries mean the repo has no project binding - bind it in the Installations panel. signature_failed or errored deliveries indicate a platform-side problem; check Rensei's audit logs.
"API rate limit exceeded"
Wait for the hourly window to reset, and reduce per-run API calls by caching results in workflow steps.
Next steps
- GitHub Issues (tracker) - use GitHub Issues as a project issue tracker
- Workflow triggers - configure when workflows run
- Expressions - use GitHub trigger data in downstream steps
- Agent sessions - watch agents interact with GitHub in real time