Last updated: September 7, 2026

Use GitLab in Chat and Automations

How Agent0 clones GitLab repositories and works with merge requests as the person who asked, and how GitLab events trigger automations.

GitLab is the connector Agent0 uses to read source code and propose fixes on GitLab.com and self-managed instances. When an investigation points to code, or when you ask for a merge request, Agent0 clones the project, reads the relevant files, and opens the merge request. You never run git or glab commands yourself.

Note

GitLab must be configured before Agent0 can use it, and that takes two steps. An administrator connects the organization, and you connect your own GitLab account. See Set Up GitLab Integration.

Agent0 Acts as You

Every GitLab operation runs with a token belonging to the person who asked. Four consequences follow:

Your name is on it. Clones, pushes, merge requests, comments, and approvals are attributed to you in GitLab, not to a Dash0 bot.
Your permissions bound it. If you cannot see a project, neither can Agent0. A "404 Project Not Found" usually means your GitLab account lacks access.
No bot fallback. Without your personal connection, the operation fails and Agent0 asks you to connect. The organization's service account is never substituted.
Identical everywhere. The same rules apply whether you ask in Dash0 Chat, in Slack, or in Linear. In an automation, there is no interactive user, so Agent0 acts as the automation's creator instead. See Use GitLab in Automations.

Where GitLab Works

GitLab is available on the interactive surfaces where Dash0 knows who is asking:

Dash0 Chat
Slack
Linear

GitLab events also trigger automations. The automation acts as its creator rather than as the requesting user. See Use GitLab in Automations.

What Agent0 Uses GitLab For

Follow telemetry to code: Logs, spans, and metrics may carry the vcs.repository.url.full attribute, which identifies the repository of the application that emitted them. Agent0 uses it to tie a signal to the GitLab project it came from.
Read projects: Inspect implementations, configuration defaults, error definitions, and tests.
Fix bugs: Apply a change on a feature branch and open a merge request with full context.
Review merge requests: Read merge request contents, diffs, and pipeline results.
Read issues and pipelines: Pull in issue context and CI status during an investigation.
Link telemetry to merge requests: Include deep links to the relevant spans, logs, or failed checks in the merge request description.

Example Chat Requests

You ask	What Agent0 does
"Where in the code does this error come from?"	Follows the repository URL from the span, clones the project, and finds the relevant source
"What's the default timeout for this service?"	Clones the project and inspects the configuration
"Fix this bug and open a merge request"	Creates a feature branch, commits the fix, pushes, and opens a merge request with Dash0 deep links as context
"What's changed in merge request 412?"	Reads the merge request contents and diff
"Did the pipeline pass on my branch?"	Reads the pipeline status for that branch

Use GitLab in Automations

GitLab events start automations. Two trigger types are available:

GitLab: Merge Request fires on merge request activity: opened, closed, reopened, merged, approved, and updates such as new commits.
GitLab: Comment fires when a comment is added to a merge request, issue, commit, or snippet, with an optional keyword filter.

Both triggers need the integration's webhook registered in GitLab, on a group or on a project. For the trigger fields and variables, see Configure Triggers.

An automation has no interactive user, so the acting-user rule works differently than in Chat:

Agent0 acts as the automation's creator. Every clone, read, push, merge request, and comment is attributed to the person who created the automation, bounded by their GitLab permissions.
No bot fallback still holds. GitLab has no shared bot identity, so if the automation has no usable creator connection, GitLab work fails rather than falling back to a service account.
Read-write work needs a read-write connection. If the creator connected GitLab in read-only mode, writes are refused.
API, CLI, and Terraform automations have no creator. An automation created outside the editor has no recorded acting user and cannot act in GitLab.

When there is no one to act as, Agent0 raises the gitlab_automation_no_acting_user warning and does not retry.

How Agent0 Reaches GitLab

There are no dedicated GitLab tools. Two command-line tools are the whole interface, and Dash0 injects your credentials into each invocation:

git handles repository content: clone, branch, commit, and push.
glab handles everything else: merge requests, issues, pipelines, and any other API object through glab api.

Limits Worth Knowing

Pushes to the default branch are refused. Agent0 always works on a feature branch and opens a merge request. To iterate on an open merge request, ask Agent0 to push more commits to the same branch rather than opening a new one.
Read-only over MCP. When Agent0 is invoked through the Dash0 MCP with a read-only action scope, writes are refused before GitLab is contacted. This covers git push, creating or approving a merge request, creating issues and notes, and routing a write through glab api.
Unrecognized commands count as writes. In a read-only session, glab subcommands are matched against an allowlist of known read commands. Anything not on that list, including a command a future glab release adds, is treated as a write and refused.
Public projects clone without a connection. With no token available, git clone falls back to an anonymous read, so a public project can still be cloned if the network mode permits. Anything private, and every glab command, needs your personal connection.

Network Modes

A thread's network mode decides which GitLab hosts Agent0 can reach, and it cannot be changed from inside the thread.

Network mode	GitLab.com	Self-managed instance
`no_network`	Blocked	Blocked
`trusted_only`	Reachable	Blocked
`full`	Reachable	Reachable

GitLab.com is one of Agent0's default trusted hosts. A self-managed instance is not, and the trusted-host list cannot be extended from a thread, so self-managed work needs the full network mode. Agent0 raises the gitlab_network_level_blocks_clis warning up front instead of failing partway through a task. To reach a blocked host, start a new thread with a network mode that covers it.

Self-Managed Instances

Your organization can connect a self-managed instance instead of, or alongside, GitLab.com. Agent0 resolves the host from the project's Git remote, so inside a clone both tools target the right instance automatically.

Outside a clone, name the instance with a full URL:

bash

1
glab mr list -R https://gitlab.example.com/group/project

The URL form is required because GitLab allows dots in group names, so a value like host/group/project cannot be told apart from a nested group such as org.name/team/project.

Merge Request Links in the Thread

When Agent0 opens a merge request, the thread renders it as a link chip that you can click through to GitLab. This works for self-managed instances as well as GitLab.com. You can also attach a GitLab URL to a chat message as a context item to point Agent0 at a specific project, merge request, or issue.