Azure DevOps integration

Connect cloud agents to Azure DevOps repos using personal access tokens and Warp-managed secrets.

Cloud agents work with any Git repository, including those hosted on Azure DevOps. For a standalone cloud agent environment, grant access with a personal access token and Warp-managed secrets. Once configured, the environment works with any Automation Platform trigger—Slack, Linear, schedules, or the CLI.

This approach works for both Azure DevOps Services (dev.azure.com) and Azure DevOps Server (self-hosted) instances.

To connect hosted Azure DevOps Services to a factory with event-driven automations, use the Azure DevOps factory integration. For an Azure DevOps Server factory, use the other code forges setup.

Prerequisites

Warp account - <a href=https://oz.warp.dev>Create an account in the Oz web app.
Azure DevOps repository - Use a repository hosted on Azure DevOps Services or Azure DevOps Server.
Oz CLI - Install and authenticate the CLI.

Generate a personal access token

Sign in to your Azure DevOps organization at dev.azure.com/{your-org}.
Click the user settings icon (gear) in the top-right corner, then click Personal access tokens.
Click + New Token.
Enter a descriptive name for the token (e.g. warp-oz-agent), choose the organization it applies to, and set an expiration date that matches your team's rotation policy.
Under "Scopes," choose Custom defined, then select Code > Read.
Click Create.
Copy the token value immediately. Azure DevOps will not show it again.

Code (Read) is the minimum required scope to clone a repository. If a future workflow requires the agent to push commits or open pull requests, you will also need Code (Read & Write).

For Azure DevOps Server (self-hosted), sign in at https://{server}/{collection} instead of dev.azure.com. The token creation steps are the same.

Store the token as a Warp-managed secret

Warp injects managed secrets as environment variables at runtime and never exposes them in logs or configuration files. See the Secrets documentation for full details on scoping and managing secrets.

Run the following command:

oz secret create --team AZURE_DEVOPS_TOKEN

When prompted, paste the token.

The value is stored and encrypted, and cannot be retrieved after creation.

Use --team to create a shared token available to all teammates and automated triggers (schedules, Slack, Linear). Use --personal if each team member should authenticate with their own Azure DevOps token. Personal secrets work with all triggers and take precedence over a team secret of the same name when both exist.

If you need to update a secret value, run:

oz secret update --team --value AZURE_DEVOPS_TOKEN

Create an environment with a clone setup command

Create an environment that uses your token to clone the repository at the start of each agent run. Because the --repo flag in oz environment create is designed for GitHub repositories, you clone your Azure DevOps repo via a setup command instead.

Run the following command:

oz environment create \
  --name "my-azure-devops-env" \
  --docker-image <image> \
  --setup-command 'AUTH_HEADER=$(printf ":%s" "$AZURE_DEVOPS_TOKEN" | base64 | tr -d "\n") && git -c "http.extraheader=Authorization: Basic $AUTH_HEADER" clone https://dev.azure.com/your-org/your-project/_git/your-repo' \
  --setup-command 'cd your-repo && <install dependencies>'

Use single quotes around setup commands that reference secrets. Double quotes cause your shell to expand $AZURE_DEVOPS_TOKEN immediately (to nothing), rather than letting Warp inject the secret at runtime inside the container.

Replace the following placeholders:
- <image> with your Docker image (for example, node:22, python:3.12, or a Warp prebuilt dev image)
- your-org with your Azure DevOps organization name
- your-project with your Azure DevOps project name
- your-repo with your repository name
- For Azure DevOps Server (self-hosted), replace dev.azure.com with your server's hostname.
- The second --setup-command with any dependency install or build steps your project requires. For example, npm ci or pip install -r requirements.txt.

Setup commands run on a fresh container for every agent run. Write them to be idempotent — commands that assume existing state (such as a partially cloned repo or a pre-built cache) can fail unpredictably. See environment design and best practices for guidance.

Note the environment ID returned. You will need it to test the environment.

Test the environment

Before connecting to integrations, verify the environment works by running a one-off agent.

Run the following command, replacing `` with the environment ID from the previous section:

oz agent run-cloud --environment <ENV_ID> --prompt "Your task here"

Next steps

With your environment configured, you can connect it to any Warp trigger exactly as you would with a GitHub-backed environment:

Slack — Tag @warp in a message to start an agent run against your Azure DevOps repo. See Slack.
Linear — Tag @warp on an issue to kick off a workflow. See Linear.
Scheduled agents — Run agents on a recurring schedule. See Scheduled Agents.
Warp Factories — Connect hosted Azure DevOps Services with dedicated identities and event triggers. See the Azure DevOps factory integration.