BlueByte
We couldn't connectFixed

Microsoft Teams: "We couldn't connect. Try again."

By Haneul SeoUpdated September 12, 20265 min

Hi, it's BlueByte. You open Microsoft Teams, the window loads to a spinner, and it stops on We couldn't connect. Try again. — or the app sits on the loading splash forever, or the sign-in screen shows a code like 0xCAA70007 or 0xCAA20003. Nothing on your machine is broken; Teams just can't finish the handshake it needs to sign you in. We'll walk through what those messages mean, how to tell the causes apart, fix each one with runnable steps, and keep it from coming back.

What "We couldn't connect" and the CAA codes are telling you

Teams shows a few variants of the same story:

We couldn't connect. Try again.
We ran into a problem. Reconnecting…
Status code: 0xCAA70007
Status code: 0xCAA20003

Each one means the client reached a point in sign-in — loading its local state, then asking Microsoft's identity service for a token — and couldn't complete it. The plain We couldn't connect usually points at stale local state; a 0xCAA status code points at the token exchange itself, and the last four hex digits narrow it down. None of them means your account is gone.

The five things that break Teams sign-in

Teams fails to connect for one of these concrete reasons:

  • A corrupted local cache — stale tokens and config the client can't reconcile, so it loops on reconnect.
  • A wrong system clock — if the date or time is off, TLS to a secure endpoint fails, and Teams reports 0xCAA20003.
  • The network or a firewall is blocking the identity endpoints — Teams can't reach login.microsoftonline.com, shown as 0xCAA70007 or 0xCAA82EE2.
  • Wrong credentials — the email or password is off, reported as 0xCAA90018.
  • A tenant or licensing problem — your admin disabled the app or the subscription lapsed, so no token is issued for you at all.

The first two you fix yourself in a minute. The last three you confirm quickly, then either fix or hand to your IT admin.

First, find out which Teams you're running

The cache path differs between classic Teams and new Teams, so check which one you have before deleting anything:

Get-AppxPackage -Name MSTeams | Select-Object Name, Version
Name     Version
----     -------
MSTeams  <build number, varies by update>

If a line comes back naming MSTeams, you're on new Teams. If the command returns nothing, you're on classic Teams. Note the code shown at the bottom-left of the sign-in screen too — you'll use it below.

Clear the cache to fix stale local state

This is the fix for the plain We couldn't connect loop. Quit Teams fully first — a running process re-locks the files. On classic Teams:

Get-Process -Name Teams -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item -Path "$env:APPDATA\Microsoft\Teams\*" -Recurse -Force

On new Teams:

Get-Process -Name ms-teams -ErrorAction SilentlyContinue | Stop-Process -Force
Remove-Item -Path "$env:LOCALAPPDATA\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\*" -Recurse -Force

On macOS, quit Teams (⌘-Q) and clear it from Terminal — classic uses rm -r ~/Library/Application\ Support/Microsoft/Teams; new Teams uses rm -rf ~/Library/Group\ Containers/UBF8T346G9.com.microsoft.teams and rm -rf ~/Library/Containers/com.microsoft.teams2. Nothing here touches your messages or files — those live in the cloud; you're only deleting the local copy Teams rebuilds on the next launch. Restart Teams and sign in; the first start is slower because the cache is being rebuilt.

Fix a clock that's breaking the secure connection

If the code is 0xCAA20003, the machine's clock is off and TLS to Microsoft's endpoints is failing. Resync it:

w32tm /resync
Sending resync command to local computer...
The command completed successfully.

Then confirm the date, time, and time zone are right in Settings. On macOS or Linux, enable automatic time (sudo timedatectl set-ntp true on Linux). A clock more than a few minutes off is enough to break the handshake.

When it's the network, the credentials, or your tenant

For 0xCAA70007 or 0xCAA82EE2, Teams can't reach the identity service. Confirm the endpoint is reachable:

Test-NetConnection login.microsoftonline.com -Port 443
TcpTestSucceeded : True

If that comes back False, a firewall, proxy, or VPN is in the way — work with your IT admin to allow the Microsoft 365 endpoints. For 0xCAA90018, sign in again with the correct email and password. And if no one in your organization can sign in, or the code maps to a disabled app, that's a tenant or licensing issue only your admin can clear — note the exact status code and send it to them.

A real case: classic Teams stuck on the spinner

A user's classic Teams opens to the loading spinner and lands on We couldn't connect. Try again. The clock is correct and other apps reach the internet, so it's local state. Get-AppxPackage -Name MSTeams returns nothing, confirming classic Teams. You quit it, run the two classic-Teams commands above to clear %APPDATA%\Microsoft\Teams, and relaunch. The first start takes about twenty seconds while the cache rebuilds, then sign-in completes and Teams stays connected. The account and data were fine the whole time — only the local cache was wedged.

Confirm Teams signs in and stays connected

After the fix, Teams should reach your chat list and stay there, not bounce back to Reconnecting…. Send yourself a message and reload; if it persists and presence shows you online, sign-in is healthy. If it still can't connect, re-read the status code — a different code means a different cause on this list, not a failed cache clear.

Keep it from coming back, and how it differs from Outlook not starting

Let new Teams update itself rather than pinning an old build, keep the system clock on automatic time, and quit Teams cleanly instead of killing it mid-write so the cache isn't left half-written. This is a different failure from Outlook's Cannot start Microsoft Outlook — that one is a broken local profile or OST and is fixed by repairing the profile, not by clearing a Teams cache. Both are local-state problems, but they live in different apps and different folders. Next time Teams won't connect, read the status code first, then walk this list from cache to clock to network.

Related questions

Will clearing the cache delete my chats or files?

No. Messages, files, and channels live in Microsoft 365, not in the cache. You're deleting the local copy Teams rebuilds on the next sign-in; the only cost is a slower first launch.

I'm on new Teams and the classic %APPDATA% path is empty.

That's expected — new Teams stores its cache under %LOCALAPPDATA%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache, not %APPDATA%\Microsoft\Teams. Run Get-AppxPackage -Name MSTeams to confirm which you have, then clear the matching path.

The code is 0xCAA20003.

Your clock is off and TLS is failing. Run w32tm /resync, then fix the date, time, and time zone. A clock skewed by minutes is enough to break sign-in.

Everyone in my company hit this at once.

That points at the tenant, not your machine — a lapsed subscription or an app your admin disabled. Clearing your cache won't help; send the status code to your IT admin.

It connects, then drops back to "Reconnecting…".

That's usually the network dropping the long-lived connection — a flaky VPN or proxy. Test with Test-NetConnection login.microsoftonline.com -Port 443; if it fails intermittently, the path to the endpoint is the problem, not Teams.

References

Haneul Seo

Infrastructure engineer · 10+ years running Linux fleets

More in this category

5.7.26Fixed

Gmail rejects your mail with 550-5.7.26: unauthenticated email is not accepted due to the domain's DMARC policy

Gmail enforced the DMARC policy your own domain publishes: the message failed both SPF and DKIM alignment against the header From: domain, so a p=quarantine or p=reject policy turned it into a hard bounce. The Authentication-Results header names the failing check, and three dig queries against your SPF, DMARC and DKIM records name the cause. A near-identical bounce about authenticating with SPF or DKIM is a different problem — Gmail's baseline sender requirements, not your policy.

Gmail / Google Workspace
AADSTS50011Fixed

Microsoft Entra ID: AADSTS50011, the redirect URI specified in the request does not match the redirect URIs configured for the application

Sign-in completes and then Entra ID refuses the last hop, because the redirect_uri your app sent is not a byte-for-byte match for any URI registered on the app. The match is case-sensitive, counts the trailing slash, requires https outside localhost, and treats the port as significant everywhere except localhost. It also splits by platform: web, spa and publicClient are three separate lists, and URIs added to the service principal instead of the application object can disappear. Read the URI and the app ID out of the error, compare them with az ad app show, add the exact string with az ad app update or a Graph PATCH, then wait three to five minutes.

Microsoft Entra ID
535 5.7.139Workaround

Exchange Online: 535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled

A scanner, script or app that sends through smtp.office365.com gets 535 5.7.139 because the SMTP AUTH protocol is switched off for the tenant, for that mailbox, or by an authentication policy or security defaults that block Basic authentication. Read the wording (Tenant, Mailbox, or 'did not meet the criteria'), confirm with Get-TransportConfig, Get-CASMailbox and Get-AuthenticationPolicy, then open SMTP AUTH on the one mailbox that needs it rather than tenant-wide. Treat Basic SMTP AUTH as a bridge: Microsoft disables it by default for existing tenants at the end of December 2026, so move the sender to OAuth, High Volume Email or a relay connector.

Exchange Online (Microsoft 365)
Error code: 5003Fixed

Zoom: "Unable to connect" error code 5003 — the desktop app can't reach Zoom while the browser can

Error 5003 is the Zoom desktop app failing to complete its connection to Zoom's servers while the web client on the same machine joins fine. The app needs more than a browser does: Zoom's firewall article lists TCP 443/8801/8802 and UDP 3478/3479/8801–8810 for meetings, a set of CA hosts for certificate validation, and it asks that zoom.us and *.zoom.us be exempted from proxy or SSL inspection. A port test, a curl issuer check, and the app's built-in Network Connectivity Tool (Ctrl+Alt+Shift+D / Cmd+Option+Shift+D) show which of those is cut; fix that layer, and reinstall only when a single machine fails while its neighbours join.

Zoom
Slack cannot connect. / Last updated less than a minute ago…Fixed

Slack: "Slack cannot connect" and the grey "Last updated…" banner behind a corporate proxy

Slack loads channels over ordinary HTTPS but delivers new messages over a persistent WebSocket on port 443 to the three wss-*.slack.com hosts Slack names (primary, backup, mobile). When a proxy or firewall passes the HTTP side and blocks the upgrade — most often because SSL decryption is on for the wss hosts, or the allowlist stops at slack.com — the app shows the grey "Last updated…" banner or "Slack cannot connect." while the browser seems fine. Two curl probes from the affected machine show which layer is blocked; exempt the three wss hosts from decryption, allow every domain on my.slack.com/help/urls, and confirm with my.slack.com/help/test.

Slack
locked for editingFixed

Word: "The document is locked for editing by another user"

Word found a lock — an owner file — for the document and assumed someone else has it open, so it offers only a read-only copy. Usually no one does: a crash left the lock behind, or a hidden Word process is still holding the file. Confirm which, close every Word instance, delete the stale ~$ owner file, and the document opens for editing again.

Microsoft Word