DevOps

A DevOps tab shows one project on Azure DevOps or one repository on GitHub. It has three sections: Runs, Pull requests and Work items (on GitHub: Issues).

Nothing the tab reads is stored. Runs, logs and tickets live in the tab and are gone when you close it. Only the account and its token are saved, sealed with the master key.

Accounts

An account is one Azure DevOps organisation or one GitHub owner (your user or an organisation), with the token for it. Its projects open in DevOps tabs.

You need one account per token, because that is how both sides hand tokens out:

• Azure DevOps: make a token for this organisation only. Global tokens stop working on 1 December 2026.
• GitHub: a fine-grained token has one resource owner. Your own repositories need one account, each organisation another.

Add an account

1. Open Settings with Ctrl+Shift+, and go to Accounts.
2. Paste any link from the organisation or one of its projects, such as https://dev.azure.com/organisation/project/… or https://github.com/owner/repo, and click Add. Vandle reads the provider and the owner from the link.
3. The dialog lists the permissions to tick. Make one opens the page where the token is made, in your browser. Make it there and paste it.
4. Pick the route, then Check and save.

You can also start from New tab: pick DevOps, paste a link, and the account is added on the way.

The check uses read calls only. It shows who the token belongs to and which read permissions it has. A missing write permission cannot be checked without changing something, so it shows when you first need it, with the permission named in the message.

Permissions to tick

Azure DevOps	For
Build: Read & execute	runs, logs, start
Release: Read, write, execute & manage	releases, approvals
Pipeline Resources: Use	environment approvals
Code: Read & write	pull requests, votes, merge, the commit of each run
Work Items: Read & write	tickets, comments
Project and Team: Read	the list of projects

GitHub	For
Actions: Read and write	runs, logs, start, cancel, re-run
Deployments: Read and write	approvals
Contents: Read and write	workflow files, merge, delete branch
Pull requests: Read and write	reviews, comments
Issues: Read and write	tickets, comments
Commit statuses, Checks, Metadata: Read	checks on a pull request

Route

Every tab of an account takes the account's route: direct, through a proxy or through ProxyPass. See Routes.

A token that expired

When the provider refuses the token, the tab says so and offers a field for a new one. It is checked first; every open tab of the account then takes it. Under Settings, Accounts, New token does the same.

Open a project

1. Press Ctrl+Shift+T and pick DevOps.
2. Pick the account. Its projects or repositories are listed live; type to filter them.
3. Press Enter on the project.

Paste a link to a project of an account you already have, and the project is offered at once. The pin beside a project in the list pins it to the sidebar.

The header shows the project, the provider, the sections with their counts and when the tab last heard from the server. The tab reads again about every 30 seconds while it is on screen, and stops while it is hidden. Open on web shows the same page on the provider's site in a Web tab, over the account's route.

Runs

The left side lists what can run, grouped: Releases (classic release pipelines, Azure only), Pipelines and Workflows (GitHub Actions). Each shows how its last run went. Pick one to see its runs: status, name, branch, one bar per stage (per job on GitHub), who started it, when, and how long it took. Load older runs goes further back.

Under each run's name is the commit it built: the first line of the message, the short commit id, when it was committed and by whom. A classic release shows the commit of its primary build artifact. A commit never changes, so Vandle keeps the ones it has read, encrypted with your master key, and asks Azure DevOps only for new ones; removing the account removes them. On Azure DevOps this needs Code: Read; without it a run shows the commit message only when a CI trigger carried it. For a pipeline on a GitHub repository, Azure DevOps hands over the message of CI runs only.

Follow a run

Click a run to open it. The commit stands under its name. The stages run along the top; click one to see its jobs and steps. Click a step to read its log.

A classic release lays its stages out as Azure DevOps does: a box on the left says what started the release and which artifacts it deploys, and each stage stands behind the stages it waits for, so stages that run side by side get a row each. A stage that only starts by hand has no line to the box.

• A failed run opens on the failed step, and the log jumps to the first error. Jump to first error does that again.
• Copy copies the log as shown.
• A log appears once its step has finished. While a step runs, the step list updates live.
• On GitHub a job has one log. It is shown whole, scrolled to where the step begins.

Start a run

Run (or Create release for a classic release) opens the start dialog. It is filled with the values of the last run. Ctrl+Enter starts.

• YAML pipeline: the branch, the parameters by their type, and the stages to run. Untick a stage to skip it.
• GitHub workflow: the branch and the workflow's inputs. GitHub cannot skip jobs at start.
• Classic release: the artifact version (the newest build unless you pick another), which stages deploy on their own and which stay manual, and the variables that may be set at release time.

Run again with these inputs in an open run fills the dialog with that run's values.

Cancel, rerun, deploy

• Cancel stops the run.
• On Azure DevOps, Rerun failed jobs of this stage runs the failed jobs of the chosen stage again. On GitHub, Rerun failed jobs and Rerun all jobs work on the whole run.
• A stage of a classic release that has not been deployed yet has Deploy on its card. A deployed one can be deployed again.

Each of these asks first.

Approvals

When a stage waits for your approval, a banner sits above the steps of that run: who may approve, since when, a comment field, Approve and Reject. Both ask first.

You see it from elsewhere too:

• the Runs section header counts the approvals that wait for you,
• the tab's row in the sidebar is marked, its tooltip names the stage,
• a desktop notification appears, once per approval. A click on it brings Vandle to the front with that run open.

The approvals are checked every two minutes, also while the tab is hidden. No notification comes for an approval that appears while its tab is in front.

On Windows, notifications appear only in the installed Vandle: Windows needs the Start menu shortcut the installer creates. On Linux they go to the desktop's notification service; if it does not report clicks, the notification still informs.

Pull requests

The list shows the open pull requests under three filters: Waiting for my review, Created by me and All open. Each row has the author, the title (with a Draft mark), the branches, the checks, the reviewers with their vote and the number of active comments. The section header counts all open pull requests and how many wait for you.

Click a pull request to open it. The header has the branches, the checks, the reviewers, the Vote (Azure DevOps) or Review (GitHub) button and Complete… (Azure DevOps) or Merge… (GitHub). Open on web shows the open pull request in a Web tab.

Overview

• the description, formatted from its Markdown,
• the discussion: comments with their replies, and a box for a new comment. Comments post at once. On GitHub each comment stands on its own; there is no reply to one, only a new comment,
• the checks and policies. A build validation links to its run, which opens in the Runs section of the same tab,
• the reviewers and their votes,
• on Azure DevOps the linked work items.

Files

The Files tab lists the changed files with their added and removed lines. On Azure DevOps, which does not count lines in its file list, the counts appear once a file's diff has been read. A dot marks a file with active comments.

Click a file to see its diff. Inline shows old and new lines one under the other, Side by side in two columns; Vandle remembers the choice for every pull request. The code is highlighted by the file's type. Alt+↓ and Alt+↑ go to the next and the previous file.

• Mark as viewed dims a file in the list. It lasts as long as the tab is open and is not stored.
• A very large file - more than 3000 changed lines, or one GitHub sends without its changes - shows Show the file instead of its diff, and is compared when you click it.
• A binary file is not compared. A change in whitespace only is shown and marked as such.

Comments on lines appear below their line, with their replies, Reply and Resolve or Reopen. Click a line number on the new side to comment on that line:

• On Azure DevOps the comment posts at once.
• On GitHub it is added to your review (Add to review) and marked Pending until you submit the review. Pending comments live in the tab; closing it drops them.
• Resolving needs GitHub's GraphQL interface. If the token is not allowed to use it, Resolve does not appear on GitHub.

Vote and review

• Azure DevOps: Vote offers Approve, Approve with suggestions, Wait for author, Reject and Reset vote.
• GitHub: Review takes an optional comment and submits your review with Approve, Request changes or Comment, together with the pending line comments. A review without a verdict needs a comment or a line comment.

Approving and rejecting (on GitHub: Approve and Request changes) ask first. Comments never ask.

Complete and merge

Complete… or Merge… opens a dialog:

• the merge type: on Azure DevOps merge (no fast-forward), squash, rebase and fast-forward, or semi-linear; on GitHub the methods the repository allows,
• the commit message, filled in already,
• Delete the source branch (not offered for a branch in a fork on GitHub),
• on Azure DevOps Complete linked work items when there are any,
• Set auto-complete (Azure DevOps) or Merge automatically when all checks pass (GitHub, when the repository allows auto-merge and the token may use GraphQL).

The policies are listed. While one blocks, the Complete or Merge button stays disabled; auto-complete stays available and finishes the pull request once they pass. Completing, merging and setting auto-complete ask first.

On GitHub the merge waits until GitHub reports it done; the source branch is deleted only then. When a merge queue holds the pull request, the branch stays.

Work items and issues

The list shows your open tickets. The filter on top chooses which:

• Assigned to me: open work items or issues assigned to you.
• Mentioned: where you were mentioned. On Azure DevOps that is the last 30 days, as Azure keeps it.
• Current sprint (Azure DevOps only): the open work items of the team's current sprint.

The section header counts what the list holds. On Azure DevOps, "open" leaves out everything in a done or removed state.

Click a ticket to read it: type, number, state, who it is assigned to, the iteration (on GitHub the milestone or the labels), the description and the comments.

• On Azure DevOps the description and comments are shown as text, without their formatting. Pictures and scripts in them are not shown.
• On GitHub they are shown as written, in Markdown.

Add a comment posts below the others. Changing the state or editing the ticket happens on the web: Open on web opens the ticket in a Web tab.

Linked runs and pull requests

Under Linked:

• a run (an Azure build) opens in the Runs section of the same tab,
• a linked work item opens in place,
• a pull request opens in the Pull requests section of the same tab. On GitHub, the pull requests listed are those of the same repository that mention the issue.

AI agents

An agent connected to Vandle - see AI agents - can read an open DevOps tab: the pipelines, runs, steps and their logs, the approvals that wait for you, the pull requests with their checks, discussion and diffs, and the tickets. It reads through the tab's own connection and never gets the account or the token.

It can also ask to act: start, cancel or rerun a run, deploy a stage, approve or reject, comment, reply, resolve a thread, vote or review, merge or complete, and comment on a ticket. Each time, the tab opens the run, the start form, the pull request or the ticket, and Vandle asks you in a dialog that begins with "An agent wants to" and says what will happen. Nothing happens unless you confirm, and a no stands: the agent is told not to try again another way. This includes comments, which post at once when you write them yourself.

When something does not work

Set the environment variable VANDLE_DEVOPS_TRACE=1 and start Vandle. It works in every build, also the installed one. Vandle's log then gets one line per call to Azure DevOps or GitHub:

• the method and the address, with your organisation, owner, project and repository replaced by placeholders,
• the answer's status and how long it took, and whether it was tried again,
• the rate-limit and paging headers,
• the shape of the answer: field names and counts.

It also notes once which way Vandle went where the providers leave a choice, for example whether a running step's log can be read.

The trace never writes the token, and never content: no titles, descriptions, comments or log text.

The log is in %LOCALAPPDATA%\Vandle\logs on Windows and in ~/.local/state/Vandle/logs on Linux, one file per day.