How to Fix Azure DevOps Repos Errors
Why Azure DevOps Repos Errors Are Happening to You
You opened Visual Studio or your terminal this morning, tried to push a commit to Azure DevOps Repos, and got hit with an authentication failure, a clone error, or a branch policy rejection that made zero sense. I've seen this exact situation play out on dozens of machines , across solo developers and 200-person enterprise teams , and the frustrating part is that Microsoft's error messages rarely tell you anything useful. "Git failed with a fatal error" is not an explanation. It's a door slamming in your face.
Here's what's actually going on underneath. Azure Repos gives you two completely different version control systems: Git (distributed, where your local clone is a full repository) and Team Foundation Version Control (TFVC) (centralized, where the server holds the authoritative history). Most problems developers hit fall into one of five buckets:
- Credential rot. Your Windows Credential Manager or Git Credential Manager cached a stale token, usually after a password change, an MFA reset, or an Azure AD tenant switch. The client silently retries the bad token until it locks you out.
- Azure DevOps Repos clone failures over HTTPS. Proxy servers, corporate firewalls, or outdated Git for Windows installs break the HTTPS handshake before it even starts negotiating.
- Branch policy conflicts blocking pull requests. Teams set up required reviewers, minimum approval counts, or linked build pipelines, then forget about them when someone tries to merge urgently at 5 p.m. on a Friday.
- Permission misconfiguration. The user exists in Azure Active Directory but hasn't been added to the correct Azure DevOps organization, project, or repository-level security group.
- TFVC workspace issues. Workspaces mapped to old server paths or deleted team projects cause tf.exe and Visual Studio's TFVC client to throw mapping errors that look like server problems but are actually local.
The maddening part is that these issues look identical on the surface. "TF30063: You are not authorized to access" can mean a credential problem, a permissions problem, or a network problem. You have to rule them out one by one, which is exactly what this guide does.
I know this blocks your actual work. So let's move fast. Browse all Microsoft fix guides →
The Quick Fix, Try This First
About 60% of Azure DevOps Repos connection and authentication errors clear up the moment you flush your cached credentials and let Git Credential Manager fetch a fresh token. This is step zero, do it before anything else.
On Windows (Git Credential Manager):
Open Control Panel → Credential Manager → Windows Credentials. Look for any entries that start with git:https://dev.azure.com or git:https://[yourorg].visualstudio.com. Select each one and click Remove. Do the same for any entries that say MicrosoftOffice or VSS pointing at your Azure DevOps tenant.
Then open a terminal and run:
git credential reject
protocol=https
host=dev.azure.com
(Press Enter twice after the last line to submit it.)
Now try your clone or push again. Git will pop up a browser window asking you to sign in through your Microsoft account or Azure AD. Sign in, grant the OAuth consent screen, and you're done. Your new token gets cached automatically.
On macOS (Keychain):
Open Keychain Access, search for dev.azure.com, and delete any matching entries. Then retry the Git operation.
On Linux:
git config --global --unset credential.helper
git config --global credential.helper store
Then push or clone to trigger a fresh credential prompt.
If that alone didn't fix it, also check that your Git for Windows is at least version 2.39. Run git --version in your terminal. Anything older than 2.39 has known TLS bugs that break Azure DevOps Repos HTTPS connections on certain corporate networks.
A surprising number of Azure DevOps Repos errors start at the connection step, not at the Git layer. If you set up your remote URL wrong, every subsequent operation will fail in confusing ways.
In Visual Studio 2022, the correct path to connect is: View → Team Explorer → Manage Connections (plug icon) → Connect to a Project. From there, sign in with your Microsoft or Azure AD account, and your organizations and projects will populate automatically. Do not type the remote URL manually here, let Team Explorer discover it.
In Visual Studio Code, install the Azure Repos extension from the marketplace. After installing, open the Command Palette (Ctrl+Shift+P) and run Azure Repos: Sign In. This handles OAuth automatically without you touching a credential manager.
For command-line Git, your remote URL format matters. Use the HTTPS format:
https://dev.azure.com/{organization}/{project}/_git/{repository}
Not the older visualstudio.com format, that still works but is deprecated for new connections and causes confusion with credential caching. You can update an existing remote without re-cloning:
git remote set-url origin https://dev.azure.com/myorg/myproject/_git/myrepo
After updating your remote, run git remote -v to confirm the new URL is set. If you see the correct dev.azure.com URL for both fetch and push, you're good. Now try git fetch origin, a successful fetch with no errors means the connection is established.
One thing people miss: if your organization uses a custom domain (like repos.contoso.com proxied to Azure DevOps), you need to configure Git's credential helper to recognize that domain explicitly. I'll cover that in the Advanced section.
If re-entering credentials didn't fix it and the Quick Fix didn't help either, you're likely dealing with one of three deeper authentication problems: an expired Personal Access Token (PAT), an SSH key that was never registered, or an Azure AD Conditional Access Policy blocking your sign-in.
Check your Personal Access Token. Go to https://dev.azure.com/{yourorg}/_usersSettings/tokens. If your PAT is expired or missing the right scopes, it will silently fail. Create a new PAT with at minimum the Code (Read & Write) scope. Copy it immediately, Azure DevOps only shows it once.
To use a PAT with Git over HTTPS, set it as your password when prompted (your username can be anything, many people use their email address, but the value is ignored). Or encode it into your remote URL for scripting contexts:
git remote set-url origin https://{anyusername}:{PAT}@dev.azure.com/{org}/{project}/_git/{repo}
Be careful with this in shared environments, PATs in URLs can leak into log files.
Check SSH key registration. If you prefer SSH, your public key must be registered at https://dev.azure.com/{org}/_usersSettings/keys. Run ssh-keygen -t ed25519 -C "your@email.com", copy the contents of ~/.ssh/id_ed25519.pub, and paste it into the Azure DevOps SSH Keys page. Then test with:
ssh -T git@ssh.dev.azure.com
You should see a response confirming your identity. If you get "Permission denied (publickey)", the key isn't registered or your SSH agent isn't loaded, run ssh-add ~/.ssh/id_ed25519 first.
Check Conditional Access. If your org enforces MFA or device compliance via Azure AD Conditional Access, Git operations from unmanaged devices or unapproved networks will fail with TF401349 or an OAuth error. You'll need to either use a PAT (which bypasses Conditional Access for Git) or ensure your device is enrolled in Intune. Check with your Azure AD administrator.
Clone failures are one of the most common Azure DevOps Repos issues, and one of the most multi-layered. Before assuming it's a credentials problem (you already handled that), check the actual error message carefully.
Error: "SSL certificate problem: unable to get local issuer certificate"
Your corporate network is doing TLS inspection. The proxy is injecting its own certificate, and Git doesn't trust it. Run:
git config --global http.sslCAInfo "C:/path/to/corporate-ca-bundle.crt"
Ask your IT team for the corporate CA certificate bundle. Alternatively (and only in a controlled internal network):
git config --global http.sslVerify false
Do not use the sslVerify false option on machines that access the public internet, it disables certificate validation entirely.
Error: "RPC failed; curl 56 OpenSSL SSL_read: Connection reset by peer"
This is a buffer size issue on large repos. Increase Git's HTTP buffer:
git config --global http.postBuffer 524288000
Then retry the clone. For very large Azure DevOps Repos repositories, add a shallow clone first to test connectivity:
git clone --depth=1 https://dev.azure.com/{org}/{project}/_git/{repo}
Error: "Repository not found" or 404
This one is almost always a permissions issue, not a URL issue. The repository exists, you just don't have access to it yet. Have a project administrator go to Project Settings → Repositories → [repo name] → Security and add your Azure DevOps user to the Readers group at minimum, or Contributors if you need to push.
After any permission change, wait 2-3 minutes and retry, Azure DevOps permissions propagation isn't always instant.
Branch policies in Azure DevOps Repos are designed to protect critical branches, your main or master branch especially, by requiring pull requests, approvals, and passing builds before any merge goes through. That's exactly what you want in production. But when policies are misconfigured or when you're in a legitimate emergency, they become a wall.
To see what policies are blocking your pull request, go to your PR page and look at the Policies section. Each policy shows a status: passing (green), failing (red), or waiting. The most common blockers I see are:
- Required reviewers haven't approved yet. Your PR needs N approvals and only has N-1. There's no shortcut here unless someone with Bypass Policies permission completes the merge manually.
- Build pipeline is queued or failing. Your PR is linked to a required build that's either stuck in queue or actually failing. Click the build link in the policy status to see the build log.
- "Work items must be linked" policy. You forgot to attach an Azure Boards work item to the PR. Go to the PR → Overview tab → Work Items section → link any relevant item.
- Merge strategy mismatch. The branch policy may require Squash merge or Rebase, but the PR is set to a different strategy. Check Complete merge options and align them.
To configure or review branch policies yourself (you need Project Administrator rights): navigate to Project Settings → Repos → Policies, then select your branch. From here you can see all configured policies, their required/optional status, and their current state.
If you have Bypass Branch Policies permission and genuinely need to force-complete a PR, you'll see a Complete button that includes an "Override all branch policies" checkbox. Use this only in real emergencies, bypasses are logged in the audit trail.
If your team uses Team Foundation Version Control (TFVC) rather than Git, you're working with a centralized model where the server is the single source of truth. Most TFVC errors in Azure DevOps Repos come from stale workspace mappings or corrupted local workspace caches.
The most common TFVC errors and their fixes:
TF10125: The workspace {name} does not exist
Your local workspace definition references a workspace that was deleted on the server. Open Visual Studio → View → Other Windows → Source Control Explorer. Right-click and choose Workspaces..., then delete the orphaned workspace entry and create a new one mapped to your team project path.
From the command line, you can list and delete workspaces with tf.exe:
tf workspaces /collection:https://dev.azure.com/{org}/{project}
tf workspace /delete {workspacename};{username} /collection:https://dev.azure.com/{org}/{project}
TF204017: The item $/project/path cannot be found in your workspace
Your workspace exists but doesn't have a mapping for that server path. In Source Control Explorer, right-click the root of your team project and choose Advanced → Map to Local Folder, then select or create a local folder and click Map.
tf.exe not found
The TFVC command-line client ships with Visual Studio, not as a standalone install. It lives at:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe
Add that directory to your PATH, or always call it with the full path. After resolving workspace issues, run tf get /recursive /force $/YourProjectPath to force-sync everything from the server.
Advanced Azure DevOps Repos Troubleshooting
Enterprise and Domain-Joined Machine Issues
On corporate networks, Azure DevOps Repos authentication behaves differently because Windows Integrated Authentication (WIA) tries to kick in before OAuth. This causes silent failures where Git thinks it authenticated but the token it used was rejected server-side.
To force Git to use OAuth instead of WIA, add this to your global Git config:
git config --global credential.useHttpPath true
git config --global credential.authority AAD
The useHttpPath setting tells Git Credential Manager to cache tokens per-URL rather than per-host, which prevents a credential for one Azure DevOps organization from being wrongly applied to another.
Proxy Configuration for Azure DevOps Repos
If your organization routes outbound HTTPS through a proxy, Git needs to know about it:
git config --global http.proxy http://proxy.contoso.com:8080
git config --global https.proxy http://proxy.contoso.com:8080
For authenticated proxies:
git config --global http.proxy http://username:password@proxy.contoso.com:8080
Test that the proxy is working correctly by running git ls-remote https://dev.azure.com/{org}/{project}/_git/{repo} and checking for a valid response versus a network timeout.
Custom Domain Proxies and Azure DevOps Repos
Some enterprises front-end Azure DevOps with a custom domain. Git Credential Manager needs explicit configuration to handle the credential prompt for that domain and forward tokens to dev.azure.com. Edit ~/.gitconfig and add:
[credential "https://repos.contoso.com"]
provider = generic
Then in Azure DevOps, generate a PAT and store it against that custom domain in Windows Credential Manager manually.
Event Viewer for TFVC Client Errors
TFVC client crashes in Visual Studio often leave traces in Windows Event Viewer. Open Event Viewer → Windows Logs → Application and filter by source Visual Studio or TFSPendingChanges. Error IDs in the 5000-6000 range typically point to workspace cache corruption. Delete the cache at:
%LocalAppData%\Microsoft\Team Foundation\8.0\Cache\
Then restart Visual Studio. The cache rebuilds automatically on next connection.
Group Policy Conflicts
If your IT team has a GPO that enforces Windows Credential Manager for all network authentication, it may interfere with Git Credential Manager's OAuth flow. You can check active GPOs by running gpresult /h gpresult.html and opening the resulting file. Look for any policies under Computer Configuration → Windows Settings → Security Settings → Local Policies related to network logon or credential delegation.
If you find a conflicting GPO, work with your Active Directory administrator to add dev.azure.com to the allowlist for OAuth-based credential delegation, rather than fighting the GPO yourself.
If you've worked through every step here and still can't connect, especially if the error is TF400813 (resource not authorized at the Azure AD tenant level), AADSTS50020 (guest account issues), or any error mentioning Conditional Access policies you can't modify, you're past self-service territory. This involves your Azure AD tenant configuration, which requires admin rights you probably don't have. Contact Microsoft Support and open a ticket under Azure DevOps → Access and Permissions. Have your organization URL, the exact error message, and your Azure AD tenant ID ready, you can find the tenant ID at https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Overview.
Prevention & Best Practices for Azure DevOps Repos
Once you've fixed the immediate issue, the goal is to never hit it again. Here's what I've seen actually work in practice, not generic advice, but things that prevent real recurrences.
Set PAT expiry reminders. Azure DevOps Personal Access Tokens expire silently. You won't get an email. Set a calendar reminder 2 weeks before your PAT expires and rotate it proactively. Store PATs in a password manager like 1Password or BitWarden rather than in your Git config or shell history files.
Use SSH instead of HTTPS for long-term setups. SSH keys don't expire (unless you set them to). Once your key is registered in Azure DevOps at https://dev.azure.com/{org}/_usersSettings/keys, it just works, no token rotation, no Credential Manager drama. The SSH remote URL format is:
git@ssh.dev.azure.com:v3/{organization}/{project}/{repository}
Keep Git for Windows current. New Azure DevOps features and authentication changes often require a recent Git client. Run git update-git-for-windows from any terminal, it checks and updates in place without losing your config.
Document your branch policies before enforcing them. Before turning on required reviewers or linked builds, write down exactly who is a required reviewer, what the build pipeline is called, and what the bypass permission group is and who's in it. Put this in your project wiki. At 11 p.m. when a hotfix needs to ship, you don't want to be figuring this out from scratch.
Run a weekly Azure DevOps health check. Every Monday, verify your PAT is valid, your SSH key is active, and you can successfully clone or fetch from your main repository. 30 seconds of testing beats 3 hours of emergency debugging on a deadline.
- Rotate PATs every 90 days and store them in a password manager, never in a
.envfile committed to the repo - Prefer SSH authentication over HTTPS for personal developer machines to eliminate Credential Manager conflicts
- Add
dev.azure.comto your corporate proxy's SSL inspection exemption list to prevent TLS handshake failures - Create a dedicated Azure DevOps service account for CI/CD pipelines rather than using a personal PAT that expires or changes with your password
Frequently Asked Questions
Why does Azure DevOps keep asking me for my password every time I push?
This happens when Git Credential Manager isn't installed, is outdated, or didn't save your token correctly. Open Control Panel → Credential Manager and look for an entry starting with git:https://dev.azure.com. If it's missing, Git is falling back to prompting you every time. Install the latest Git for Windows (which bundles Git Credential Manager) and then push once to trigger a fresh save. After that, your credentials should persist across sessions without being re-asked.
What's the difference between Azure DevOps Git repos and TFVC, which should I use?
Azure DevOps Repos supports both Git (distributed) and TFVC (centralized). Git is the right choice for almost every new project in 2026, it works with every major tool and platform, supports offline work, and has the largest ecosystem of integrations. TFVC made sense a decade ago for large monorepos in enterprises using Visual Studio exclusively, but Microsoft itself recommends Git for new projects. If your team is already on TFVC and the migration cost is high, staying on TFVC is fine, but don't start a new project on it.
My pull request says "1 policy not met" but I can't see what's blocking it, where do I look?
Scroll all the way down on the PR page to the Policies section, sometimes it's below the fold and people miss it. Each policy has an expand arrow that shows exactly what's failing: a required reviewer who hasn't approved, a build that failed, or a work item link that's missing. If the policy shows "waiting" rather than "failed," the required build pipeline is probably still queued. Check your pipeline queue at Pipelines → All Pipelines to see if it's stuck behind other runs or waiting for a self-hosted agent.
I get "TF30063: You are not authorized" even though I can log into Azure DevOps in the browser just fine, why?
This usually means your Visual Studio or command-line client is authenticating as a different identity than the one in your browser. You might have two Microsoft accounts, a personal one and a work one, and the wrong one is cached in Windows Credential Manager. Open Credential Manager, delete every entry mentioning Azure DevOps or visualstudio.com, then reconnect from Visual Studio. When it prompts you to sign in, make sure you choose the correct organizational account, not your personal Microsoft account.
Can I use Azure DevOps Repos with VS Code without installing Visual Studio?
Yes, absolutely, and this is a very common setup. Install VS Code, then install the Azure Repos extension from the VS Code Marketplace (publisher: Microsoft). You'll also need Git for Windows installed separately (download it from git-scm.com). Once both are installed, the Azure Repos extension handles authentication via OAuth in the browser, and your standard Git commands work through VS Code's integrated terminal. You don't need any part of Visual Studio for this workflow.
How do I give a contractor access to just one repository in Azure DevOps Repos without giving them access to everything?
Go to Project Settings → Repos → Repositories, select the specific repository, then click the Security tab. Add the contractor's Azure DevOps user (they'll need to be invited to your Azure AD tenant or your DevOps organization first) and set their permission group to Readers or Contributors depending on whether they need to push. Then go to the project-level security and explicitly set their project access to Stakeholder, this limits their visibility across the project while still allowing repo access. Test by having them try to clone the repo and verify they can't browse other repositories they shouldn't see.