GitLab Duo CLI is now generally available with GitLab 19.2. It brings the GitLab Duo agent into the terminal to explore repositories, modify code, investigate failed pipelines and automate multi-step tasks. It works in an interactive session or headlessly inside a script and runner.

General availability does not make the agent an autonomous administrator that should receive an unlimited token. The terminal concentrates source code, credentials, deployment tooling and sometimes production access. A useful trial therefore starts with a narrow scope, minimum permissions and a record of every action.

The short answer

Use caseCaution level
Understand a repository read-onlyGood starting point. Review which files reach the model.
Propose a local fixUse plan mode, then review the diff before applying it.
Diagnose CIGrant access only to the required projects and logs.
Headless execution in a runnerAdd time limits, isolation and output validation.
Production deploymentDo not grant direct access by default; retain human approval.

GitLab documents Duo CLI for Premium and Ultimate tiers across GitLab.com, GitLab Self-Managed and GitLab Dedicated. The generally available experience requires Duo CLI 9.0.0 or later.

Two installation paths

The most integrated path uses the GitLab glab command. Once authentication is configured, glab duo cli starts the experience and reuses GitLab context. Alternatively, the standalone duo tool can authenticate with a personal access token.

The first option reduces the number of extra credentials to manage. The second may fit an environment without glab, but requires creating, storing and rotating another token. In either case, never place the secret in the repository, in a command argument visible to other processes or in a CI log.

GitLab provides /doctor to inspect setup and /mcp to review available MCP servers. These checks belong in onboarding: an agent connected to the wrong project or an unexpected external tool operates with different context from what the user assumes.

Plan mode before build mode

In interactive use, Duo CLI provides a conversational workflow. Plan mode explores without changing files, while build mode can implement changes. That separation only helps when the team enforces a real review step between them.

For a failed pipeline, a sensible sequence asks for:

  1. the first failing job and observable symptoms;
  2. ranked hypotheses and supporting evidence;
  3. a plan limited to necessary files;
  4. a fix without automatic commit or push;
  5. test commands and a final diff for review.

The agent can misdiagnose a cause, add an unnecessary dependency or silence a test instead of fixing the defect. Diff review, tests and peer review remain independent controls rather than formalities after a persuasive answer.

Sessions follow the developer

GitLab says sessions can be shared across Duo CLI, the web interface and editor extensions. An investigation started in the browser can continue in the terminal with the same conversation context.

This reduces copying but also extends the context's lifetime. A session that contained sensitive material, a disproved hypothesis or incident-specific instructions can shape later actions. Teams need criteria for starting a fresh session and should avoid one general conversation across projects with different confidentiality levels.

Duo CLI supports custom instructions including chat-rules.md, AGENTS.md and SKILL.md. They can describe permitted commands, repository conventions and mandatory checks. They are still text interpreted by a model, so critical controls must also exist in system permissions and CI.

Headless mode changes the risk

Headless mode executes a goal without an interactive conversation through commands such as glab duo cli run --goal. This allows scripts or runners to analyse failures, prepare reports or generate proposed patches.

With nobody at the terminal, immediate approval of each tool disappears. Before first use, define:

  • an ephemeral container without access to the host Docker socket;
  • a project-scoped token restricted to necessary actions;
  • no production variables when the task only concerns code;
  • limits on runtime, cost and output size;
  • an artifact containing the report and diff;
  • a ban on automatic commit, push, merge and deployment;
  • human approval before any persistent change.

A headless agent should not automatically inherit every protected pipeline variable. Isolation must be enforced by the job rather than merely requested in a prompt.

MCP expands the action surface

MCP connections can give the agent access to external tools and data, enabling an investigation across repositories, tickets, documentation and observability. They also increase the number of systems that can be read or changed from one session.

Inventory each MCP server with its owner, trust level, available methods and data access. A read-only documentation connector does not carry the same risk as a tool that changes tickets or infrastructure.

Least privilege applies at every layer: GitLab identity, runner token, local tools and MCP servers. Disabling a command in instructions without removing its technical permission is a weak control.

Administering an instance rollout

On GitLab Self-Managed and Dedicated, administrators can enable or disable Duo CLI for the instance. Documentation says access is enabled by default. An organisation that does not want immediate adoption should explicitly review this setting after upgrading to GitLab 19.2.

A pilot can begin with non-critical repositories and volunteer developers. Useful measures are not generated lines but time to diagnosis, patches accepted without rework, introduced defects, refused actions and credit consumption.

The organisation must also define which data may be sent to the service and which projects are excluded. Regulated repositories, active incidents and historical secrets require a specific review of processing terms and the model in use.

A one-week test procedure

A short trial can be structured without disrupting delivery:

  1. select a demonstration repository or non-critical internal service;
  2. configure a non-admin account and restricted token;
  3. run /doctor and inspect /mcp;
  4. test three repeatable read-only tasks;
  5. allow one local modification with mandatory review;
  6. compare results with the normal manual workflow;
  7. document situations where the agent must stop and request a decision.

Headless mode should follow the interactive phase. Its first goal can summarise a pipeline or classify logs without writing to the repository. Automated patch generation comes later, with an inspectable artifact and dedicated branch.

The agent accelerates a procedure, not replaces it

Duo CLI puts AI assistance where developers encounter failures. GitLab context, pipeline awareness and continuity between web, editor and terminal can remove several interruptions.

Its value still depends on the surrounding process. Plan mode, minimum permissions, headless isolation and diff review should be treated as technical controls. With those guardrails, the agent can accelerate diagnosis and repetitive work. Without them, one command concentrates powers that engineering teams previously worked to keep separate.