Skip to main content
Replicas responds to GitHub issue comments and PR comments. Whether starting new work from a GitHub issue, iterating on a PR from Linear, or working on any existing PR, it maintains context across all interactions.

​
Setup

  1. Go to Integrations settings
  2. Select GitHub under Source control, then click Connect and authorize your account
  3. Install the Replicas GitHub App on your repositories
  4. Add repositories you want Replicas to access
That’s it! Once a repository is added to your organization, you can use @tryreplicas mentions on any issue or PR in that repository.
Each repository can only be connected to one Replicas organization. If you need to transfer a repository to a different organization, remove it from the current organization first.

​
Default branch

Each repository has a configurable default branch that controls which branch new workspaces clone, which branch the Changes view diffs against, and which branch warm pools sync to. It defaults to main. To change it, open Integrations settings → GitHub, find the repository in the Repositories table, click the pencil icon next to the branch name, enter the new branch (e.g. staging, develop), and confirm. The setting is organization-scoped and applies to every workspace and warm pool that uses the repository. Use it for repositories where your primary branch isn’t main, so workspaces start from the right branch and PR diffs are computed against the branch you actually merge into.

​
How It Works

Workspaces created from GitHub triggers use your organization’s default coding agent and model.

​
Trigger from GitHub Issues

Add @tryreplicas to any comment on a GitHub issue to start a new task.
  • Replicas creates a new workspace to work on the issue
  • The agent provides an implementation plan before making changes
  • When complete, the agent creates a PR and comments on the original issue with:
    • A link to the PR
    • A summary of the changes made
  • When the issue is closed, the associated workspace is automatically cleaned up
Each issue is linked to one workspace. All interactions on the issue route to the same workspace.

​
Trigger from Pull Requests

Add @tryreplicas to any pull request review (e.g requesting changes) or comment.
  • If the pull request was made by a Replicas agent, it will see it, make changes, and respond directly to you.
  • If the pull request was made by someone else, a new workspace and Replicas agent will be spun up.
Each PR is linked to one workspace. All interactions route to the same workspace, so the agent remembers previous work. If the workspace is sleeping, it wakes automatically.

​
Auto Respond To Review Bots And Users

You can configure an allowlist in Organization Settings → GitHub Auto Responders to automatically react to specific GitHub accounts — bots or users — without requiring @tryreplicas. Search for reviewer bots like greptile-apps[bot], coderabbitai[bot], and copilot-swe-agent[bot] (the GitHub Copilot coding agent), or paste an exact login to add a non-bot user account, then add them to the allowlist. Accounts not on the allowlist cannot trigger Replicas. If an unauthorized bot attempts to interact, it will receive a message directing org admins to add the login to the allowlist in GitHub integration settings.

​
CI/CD Failure Auto-Response

When a CI/CD check fails on a pull request linked to a Replicas workspace, the agent is automatically notified and investigates the failure. It reads the failure logs, diagnoses the issue, pushes a fix, and comments on the PR. This works with two sources of CI failures:
  • GitHub Actions workflows, triggered via workflow_run events when a workflow completes with a failure.
  • External CI checks, triggered via check_run events from any non-Actions provider that posts results through the GitHub Checks API (e.g. Mintlify, CircleCI, Buildkite).
Both sources can be independently toggled in Organization Settings → CI Failure Response:
  • Respond to CI workflows: controls auto-response for GitHub Actions failures (enabled by default).
  • Respond to CI checks: controls auto-response for external CI check failures (enabled by default).
CI providers that report status via the Statuses API or Deployments API (e.g. Vercel deployment status) are not yet covered by this feature.
The agent posts one tracker comment per PR with a table of all CI failures, their status, and notes. New failures append a row to the same comment. When several CI failures, PR comments, or PR reviews arrive while the agent is busy, the engine folds consecutive entries of the same kind into one combined turn instead of running them back-to-back. For example, if three CI jobs fail on the same PR seconds apart, the agent gets one bundled message and fixes them in a single turn. The chat history renders these as a Bundled card with one expandable sub-card per original message, and the queue panel shows an N messages badge on the entry.

​
PR Attribution

Pull requests created by Replicas agents use the Replicas bot by default. Organizations can require user attribution with Organization → Settings → Security → Require PR user attribution. When enabled, the code host tooling inside the workspace uses the triggering user’s personal code-host OAuth token, so gh pr create, GitLab merge request push options, pushes, and commit identity resolve to that user instead of the Replicas bot. Turning on the organization policy automatically enables and locks Require code host connected and Require Replicas account because attribution cannot work without both. Users can also require attribution for their own workspaces with Account → Preferences → Require PR user attribution. This works even when the organization policy is off. Required attribution needs Replicas to resolve the triggering user and that user’s connected code-host account. Workspace creation and code-host token refresh fail closed until both are available. Automation and API-key workspaces have no attached user and fall back to the Replicas bot for PR attribution.

​
PR Merge Blocking

When the organization security policy block_agent_pr_merges is enabled, agents are blocked from merging pull requests or merge requests. This prevents agents from bypassing human review by auto-merging their own work. Blocked commands include gh pr merge, direct GitHub or GitLab API merge calls, and git push to protected branches. When an agent attempts a blocked command, it receives a policy-blocked response. This is controlled by Organization → Settings → Security → Block agent PR/MR merges. It is separate from Require PR user attribution, so organizations can enforce attribution without blocking merges, or block merges without changing attribution behavior.

​
Draft Pull Requests

Workspace agents can be instructed to open every new pull request as a draft. When enabled, the agent’s system prompt includes a clause telling it to use gh pr create --draft (or set "draft": true when hitting the GitHub REST API directly). This feature is off by default and resolves in the standard order:
  • User preference (auto_draft_prs): Toggle Open new PRs as drafts in Account → Preferences to draft PRs for your own workspaces.
  • Organization preference (auto_draft_prs): Falls back to the org-level value when no user preference is set.
  • Default: false (PRs are opened as normal pull requests).
You can still ask the agent to open a non-draft PR on a specific task. The setting controls the default, not a hard ceiling.

​
Context

For issues, the context includes:
  • Issue number, title, and description
  • Your comment body
For pull requests, the context includes:
  • PR number and branch
  • Your comment or review body
  • Review state (approved, changes requested, etc.)
  • File path and diff hunk (for line comments)

​
Intended Usage

Use GitHub Issues to:
  • Start new features or bug fixes directly from issue tracking
  • Get implementation plans before code changes
  • Track work from issue to PR automatically
Use GitHub PRs to:
  • Request changes on PRs
  • Comment on specific lines
  • Ask for fixes or improvements
Start your comment with /plan to request a planning-only response with a plan link. See Plan Mode.