Managing Azure DevOps Tokens for Muppy¶
New here? Git workflows in Muppy explains the model in one page — why it works this way, and which tokens to create.
Azure DevOps works with Muppy: store a Personal Access Token as a Git PAT vault and the credential helper serves it as it does on any other provider. Two things genuinely differ here, and both are below: Azure has no per-repository token, and it authenticates git with a header rather than with a credential in the repository URL.
The Azure DevOps workflow¶
| Can Muppy cancel an authorization here? | There is nothing to cancel. Muppy builds no OAuth connection for Azure DevOps — a box is always served your PAT — so there is no Connect and no Disconnect. Revoking a token is done at Azure, and it stops every box using it. |
| Can a token describe itself? | No. Nobody has measured whether an Azure PAT can be introspected, so Muppy does not pretend to: Introspect token and Link Git Token are not shown on an Azure vault, rather than offered and refused. What you type stands as typed. |
| Do tokens expire? | Always. Azure requires an expiry when the token is created, and your organisation may cap how long it can be. Record the same date in the vault so Muppy can warn you before it lapses. |
| The trap | Azure has no per-repository token. Its finest grain is one organisation plus a scope, so an Azure token is always account-wide — and a Muppy git-helper box asks you to authorize every pull, not just pushes. Free, prompt-free reads need a token that is read-only and limited to one repository, which Azure cannot produce. |
One default token per access level, for the whole of Azure DevOps
Muppy resolves a token by host, and on Azure one host — dev.azure.com — covers
every organisation in the world. If you hold tokens for two organisations, Muppy serves
whichever is marked default for that host.
The consequence is bounded: a token for the wrong organisation draws a 403 from Azure, never access to somebody else's code. Authorizations and the Git Operations Log are unaffected — they key on the full repository path, organisation included.
visualstudio.com URLs are not supported
The legacy form is {organisation}.visualstudio.com — one host per organisation —
so serving it would need a separate Git Provider record for every organisation. Use the
dev.azure.com/{organisation}/... form of your repository URL.
How the credential reaches the box¶
On every other provider Muppy puts the credential in the repository's remote URL. Azure
authenticates with HTTP Basic in a header, so on a box that is not using the git
helper the token sits in .git/config as http.extraheader — in clear, until someone
removes it.
Switching that box to the Muppy git helper clears the header and routes git through Muppy instead; removing the helper writes it back. Both directions are one button, and the box ends where it started.
Creating the tokens¶
- Sign in to your organisation —
https://dev.azure.com/{organisation}. - Open User settings (top right) → Personal access tokens.
- + New Token. Name it, choose the organisation, and set an expiry.
- Scopes: Code (Read) for a token that only clones and pulls; Code (Read & write) for one that pushes.
- Copy the token immediately — Azure shows it once.
Store it in Muppy as a Git PAT vault:
- Server:
dev.azure.com— the bare host, with no organisation. Muppy matches the provider on exactly what git puts on the wire. - User: leave it empty. Azure ignores the username entirely and Muppy supplies one.
- Access level:
Read-onlyorRead-write, matching the scope you chose. - Token scope:
Account-wide. It is the only truthful answer on this provider — see the trap above.
What Muppy can and cannot do for you here¶
| Check what a token really is | No. Never measured, so never offered: the buttons that would ask are hidden on an Azure vault. Your Access level and Token scope entries are what the helper trusts. |
| Cancel a Muppy authorization | Nothing to cancel — Azure has no Muppy connection. Revoke the token at Azure (User settings → Personal access tokens → Revoke), which stops every box using it. |
See also¶
- Git Tokens (Dev & Non-Dev) — which token for which kind of box
- Git workflows in Muppy — sessions, authorizations and windows
- Managing GitHub Tokens — where a classic token describes itself but a fine-grained one never reports its reach
- Managing GitLab Tokens — the fullest of the provider pages