Skip to main content
Replicas responds to GitLab issue and merge request comments, maintaining context across all interactions. It works on gitlab.com and self-managed GitLab instances.

Setup

  1. Go to Organization → Integrations
  2. Select GitLab under Source control, then connect with OAuth or a service account token
  3. Add the GitLab projects you want Replicas to access
Once a project is added to your organization, mention @tryreplicas on any issue or merge request in that project.
Each project can only be connected to one Replicas organization. To move a project, remove it from its current organization first.
For a non-human organization identity, create a GitLab service account, grant it Maintainer access to each project, create a personal access token with the api scope, and select Use Service Account. Replicas validates the token before storing it and shows its expiration date when GitLab provides one.

How It Works

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

Trigger from GitLab Issues

Add @tryreplicas to any comment on a GitLab 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 opens a merge request and comments on the issue with a link and a summary of the changes
Each issue is linked to one workspace; all interactions on the issue route to the same workspace. When the issue is closed, the workspace is archived, keeping its conversation history and staying wakeable; closing an issue never deletes the workspace. If the agent cannot complete a turn started from an issue comment, Replicas posts the concrete error on the issue when available.

Trigger from Merge Requests

Add @tryreplicas to any merge request comment.
  • If the merge request was opened by a Replicas agent, it sees your comment, makes changes, and responds directly.
  • If the merge request was opened by someone else, a new workspace and agent are spun up.
Each merge request is linked to one workspace, so the agent remembers previous work. If the workspace is sleeping or archived, it wakes automatically. If Replicas cannot start the workspace agent, deliver its initial task, or complete a later turn from a GitLab note, it posts the concrete error when available.

Trigger Automations

Automations can run from GitLab merge request events including opened, updated, merged, and closed. You can filter triggers to specific projects and group follow-up MR events into the workspace created by the first matching event.

Auto Respond To Bots And Users

Configure an allowlist to automatically react to specific GitLab accounts (bots or users) without requiring @tryreplicas. Accounts not on the allowlist cannot trigger Replicas.

CI/CD Failure Auto-Response

When a GitLab pipeline fails on a merge request linked to a Replicas workspace, the agent is automatically notified, reads the failure logs, diagnoses the issue, pushes a fix, and comments on the merge request. Toggle this in Organization → Settings → CI Failure Response (enabled by default). If the pipeline-triggered agent turn fails, Replicas posts the concrete error on the originating merge request when available.

MR Attribution

Merge requests created by Replicas agents use the account connected under Organization → Integrations by default. This can be an OAuth account or a GitLab service account. Connect a personal GitLab account under Personal → Integrations to attribute merge requests to your own account. Organizations can require user attribution with Organization → Settings → Security → Require PR user attribution, which applies to GitLab as well as GitHub. See PR attribution for how the policy resolves.

MR Merge Blocking

When Organization → Settings → Security → Block agent PR/MR merges is enabled, agents are blocked from merging merge requests, the same as for GitHub PRs. See PR merge blocking.

Draft Merge Requests

With Open new PRs as drafts enabled (Personal → Preferences, or the org default), agents open new merge requests as drafts via the merge_request.draft push option. See Draft pull requests. Every merge request opened from a workspace carries a footer crediting the person who started it and linking back to the workspace. Agents set MR descriptions through the GitLab API rather than the merge_request.description push option, which cannot carry a multi-line body intact. Replicas verifies the footer once the merge request is discovered and appends it if the agent left it out, so descriptions rewritten after creation still end up with it. Only merge requests on your connected GitLab instance are reconciled, and merged and closed merge requests are left untouched. See Replicas footer.

Context

For issues, the context includes the issue number, title, description, and your comment body. For merge requests, the context includes the MR number and branch, and your comment body.

Intended Usage

Use GitLab Issues to start new features or bug fixes from issue tracking and track work from issue to merge request automatically. Use GitLab Merge Requests to request changes, comment, and ask for fixes or improvements. Start your comment with /plan to request a planning-only response with a plan link. See Plan Mode.