GitLab · GitLab Duo Agent Platform

Software Development Flow

A user-initiated GitLab Duo Agent Platform foundational flow that runs in supported IDEs. GitLab documents that it gathers comprehensive project context, creates and works through a plan in response to a prompt, runs with minimal human interaction, can modify files in the project's local file system, and stages proposed changes in the project's repository for the user to accept, modify or reject. GitLab documents a time-limited OAuth token with the ai_workflows scope linked to the user's identity, granting access to a named set of GitLab APIs bounded by the user's permissions, and warns that the flow uses an AI agent that can perform actions using the user's GitLab account.

Recorded characteristics

Function
GitLab documents the Software Development Flow as a foundational flow of the GitLab Duo Agent Platform that runs in the IDE so that the user does not have to switch contexts or tools. The documented behaviour is: the user gives the flow a software-development task as a prompt; the flow gathers comprehensive project context upfront; it creates and works through a plan in response to that prompt; it runs with minimal human interaction; and it stages proposed changes in the project's repository, with GitLab stating that the user controls when to accept, modify or reject the suggestions. GitLab states the flow understands the context of the project structure, codebase and history, that it is aware of all files available to Git in the project branch, and that it cannot access external sources or the web. The flow can be paused and its plan adjusted. GitLab warns that the Software Development Flow uses an AI agent that can perform actions using the user's GitLab account, and that large-language-model-based AI tools can be unpredictable. This record covers only the user-initiated Software Development Flow in supported IDE integrations. Developer Flow, Code Review Flow, Fix CI/CD Pipeline Flow, Convert to GitLab CI/CD, Security Review Flow, custom flows and GitLab Duo Agentic Chat are separate documented mechanisms and their behaviours are not attributed to this record.
Data access
Three distinct levels of data access are documented and are kept separate here. First, intentionally supplied project context: GitLab states the flow is aware of all files available to Git in the project branch, together with project structure, codebase and history. Second, local execution-environment accessibility: GitLab warns that the flow can access files in the project's local file system, including files not tracked by Git and files excluded through .gitignore, and that these may include sensitive information such as credentials in .env files; GitLab does not state that every locally accessible file is transmitted to the model, and no such claim is made here. Third, server-side GitLab data reached through APIs: the flow's token grants access to the documented API areas Projects, Search, CI Pipelines, CI Jobs, Merge Requests, Epics, Issues, Notes, Usage Data and Metadata (including the deprecated version endpoint). Availability of an API area is not treated here as evidence that the flow performs every operation within it. GitLab documents context exclusions that can prevent specified project content from being used as AI context for GitLab Duo Agent Platform features. API access is bounded by the acting user's GitLab permissions; this is not unrestricted GitLab account access. GitLab states the flow cannot access external sources or the web.
Actions
Can take actions
External actions
No
Human confirmation
Conditional
Permission basis
User permissions
Administrative control
Documented controls: turning GitLab Duo on or off, and the availability and enablement of the GitLab Duo Agent Platform for the relevant group, project or instance; the user's project and group access, since the flow acts through the user's own identity and permissions; the scope of the user-linked OAuth token, which limits the flow to a named set of GitLab API areas; GitLab Duo context exclusions, which can prevent specified project content from being used as AI context; and commercial controls, including GitLab Credits requirements and tier entitlement. Sandbox isolation and network egress allowlist or denylist controls documented for flows executing remotely on runners are not attributed to IDE-local execution of this flow; GitLab's security documentation records IDE-local execution as having unrestricted network access, local working-directory access and no sandbox. Tool-approval configuration documented at instance, group and project level applies to GitLab Duo Agentic Chat, which GitLab states is separate from flows.
Default state
Conditional
Availability
GitLab records the history of this flow as: introduced as a private beta in GitLab 17.4 behind a feature flag named duo_workflow; enabled on GitLab.com, GitLab Self-Managed and GitLab Dedicated and changed to beta in GitLab 18.2; generally available in GitLab 18.8 with the duo_workflow feature flag removed; and available on the Free tier on GitLab.com with GitLab Credits in GitLab 18.10. Current documented offerings are GitLab.com, GitLab Self-Managed and GitLab Dedicated, and documented tiers are Free, Premium and Ultimate. Supported IDE environments are Visual Studio Code, Visual Studio and JetBrains IDEs, each requiring the corresponding GitLab editor extension or plugin; no minimum extension version is recorded here because the capability page does not state one. Prerequisites include GitLab Duo being available and enabled, the Agent Platform being available and enabled where applicable, a supported GitLab release, a supported IDE integration, authentication, and appropriate project or group access.
Licensing
GitLab documents that GitLab Credits are required to use the Agent Platform, and records Free-tier availability of this flow on GitLab.com with GitLab Credits from GitLab 18.10. Tier entitlement is documented as Free, Premium and Ultimate. Commercial requirements are not assumed to be identical across GitLab.com, Self-Managed and Dedicated beyond what is documented.
External model or provider
GitLab states the model information for the Software Development Flow as Anthropic Claude Sonnet 4, and separately states that the flow is available on GitLab Duo with self-hosted models. Anthropic Claude Sonnet 4 is therefore recorded as the documented default model and provider for this flow, and expressly not as an immutable provider for every deployment: where a customer configures GitLab Duo Self-Hosted models, the executing model may differ from the documented default.
Limitations and uncertainty
Recorded limitations and uncertainties. 1. Persistent repository mutation is not established. GitLab documents local file modification and the staging of proposed repository changes, with the user deciding whether those changes are accepted. GitLab does not document this flow autonomously committing code, pushing commits, creating or modifying branches, creating or modifying merge requests, or triggering or interacting with CI/CD pipelines; those behaviours are documented for adjacent GitLab flows and are not attributed here. 2. The write-approval mechanism is contradictory in current documentation. The capability page states that by default only read operations are performed without explicit approval and that write operations are possible based on the user's permissions. GitLab's Agent Platform security documentation separately records human-in-the-loop as not applied to flows, while recording approval of write API tool calls and terminal commands for IDE and CLI agents and approval of write API tool calls for Agentic Chat; the Agentic Chat documentation states that session approvals apply to Chat only and not to flows. This contradiction is recorded rather than resolved by inference, and is the basis for the conditional human-confirmation classification alongside the documented final acceptance of staged changes. 3. Terminal command execution is not established for this flow specifically and is not claimed here. 4. The lifetime of the ai_workflows OAuth token is not stated for this flow and no lifetime is recorded. 5. Composite identity, documented for flows and agents executing on runners, is not applied to this IDE-local record. 6. Current evidence does not establish that GitLab Duo context exclusions prevent the local execution environment from technically accessing excluded or untracked files; context exclusion is documented as a control over AI context, not over local filesystem access. 7. Audit-event visibility is confirmed for GitLab Self-Managed instances; equivalent visibility on GitLab.com and GitLab Dedicated is not established. 8. Minimum supported IDE extension versions are not stated on the capability page. 9. GitLab states the flow generates an audit event for each API request.

Evidence