The pipeline died at 5:07 on a Friday
I still catch myself alt-tabbing back to the browser every time a pipeline breaks. Terminal, editor, browser, until I have hunted down the failing job and pasted a stack trace somewhere I can actually think about it. GitLab has made that dance a bit shorter. The Duo CLI reached general availability with GitLab 19.2 on July 16, 2026, and the pitch is simple: Duo Agentic Chat, in the shell you were already in.
What actually shipped
The short version, straight from the announcement: Duo CLI carries the Duo Agent Platform into the terminal, and your sessions travel with you. Start a plan in the CLI, keep it going in the web UI, pick it back up in an editor extension. Same context, same permissions, different surface. That continuity is the piece I care about most, because it stops me from re-explaining the same problem to the same agent three times in one afternoon.
There are two shapes to work in. Interactive mode is the conversational one you would expect, with plan and build capabilities for iterating on a change. Headless mode is the one CI teams should look at, because it drops the same agent into a job or a script, no TTY required. Two built-in slash commands worth knowing on day one: /doctor for a setup check and /mcp to inspect the MCP configuration it is wired to.
Two ways to install, one auth story
The install decision is refreshingly small. If you already run glab, the GitLab CLI, then glab duo cli gets you moving and glab handles authentication for you. If you would rather have the agent as its own binary, you can install duo standalone and hand it a personal access token. Both paths reach the same tool. Both work on GitLab.com, Self-Managed and Dedicated, and admins get an instance-level toggle to switch access on or off for their org.
The gating detail your finance-adjacent brain will want: you need Premium or Ultimate with the Duo Agent Platform turned on, and usage draws from the GitLab Credits already included with your subscription. Not free, but not a fresh invoice either.
Where I think it earns its keep
The workflows the GitLab post highlights are the ones most of us already do badly through a browser tab: chasing a failing MR pipeline, tidying up CI/CD config, refactoring across a codebase, chipping away at multi-step tasks. The example that spoke to me was debugging a failing MR pipeline from the same shell you were about to git commit from. If that shaves three context switches off a bad afternoon, engineers will feel it before they can articulate why.
The bigger structural bet is headless mode. A first-party agent that runs inside a CI job carrying the platform's own project permissions is a different animal from a third-party CLI you have to bolt in with home-grown secrets, tokens and a trust story you invented yourself. I want to point this at a real repo before I get too excited, but the auth model is the interesting part.
Rough edges I would want on the packaging
A few honest caveats before you turn it loose. Terminal agents live and die by how well they read your project, not the marketing project, so the first afternoon will go on teaching it what your monorepo actually looks like. The Credits meter is another variable to reason about the moment you let agents run in CI at any real cadence. And a shared session across surfaces is only as strong as the permissions layer underneath it, so the admin toggle is not a nice-to-have, it is the thing you should audit before flipping this on for a whole group.
What I am watching next
Two things. First, whether headless mode in CI genuinely cuts triage time on real merge-request failures, or whether it settles into being an expensive stack-trace summariser. Second, whether the shared-session promise holds up when three people on the same team pick up the same thread from three different surfaces on the same day. If it does, this stops being a novelty and starts being how the day flows. Try it, then come back and tell me whether your Friday afternoon got a little quieter.
