A deep dive into the most absurdly persistent bug in Microsoft Teams and the one fix that actually works.
Let me set the scene.
It’s 1 AM. I’m on my brand new M1 Max MacBook Pro. I’ve just signed out of Microsoft Teams. Simple, right? Click profile, click sign out, move on with life. Except when I click “Sign in” again, my old work account is still sitting there. Staring at me. Smiling. Refusing to leave.
“That’s fine,” I think. “I’ll just clear the cache.”
Three hours later, I’ve deleted every Microsoft-related file on my machine, nuked two keychain databases with raw SQL, uninstalled every Microsoft app, wiped browser cookies, checked Microsoft’s cloud servers, and even consulted two different AI assistants, and the accounts are still there. Like ghosts. Like Microsoft built a horcrux system into Teams.
This is the story of how I finally killed them.
Why This Matters
Before you think “bro just ignore it” no. I’m the kind of person who can’t have a dead pixel on their monitor, can’t leave a single unread notification badge, and absolutely cannot have random old accounts cluttering up a sign-in screen on my brand new machine. This was a fresh MacBook. A clean start. And two ghost accounts from past lives were squatting on my Teams welcome screen like they paid rent.
It’s a matter of principle. My machine, my rules.
And based on the dozens of unanswered Microsoft Q&A threads I found, I’m far from alone. People have been fighting this bug for over a year. Microsoft’s own support team eventually admitted, and I quote, that “the new Teams client uses a deeply integrated identity system that caches credentials persistently” and that “there’s no supported script or manual method to fully remove these cached accounts.”
Cool. Love that for us.
The Journey: Everything That Didn’t Work
Here’s the thing about debugging, you learn as much from what fails as from what succeeds. So let me walk you through every single thing I tried, why it seemed like it should work, and why it didn’t.
Round 1: The Obvious Stuff
Signing out of Teams and clearing the cache.
Every guide on the internet starts here. Go to ~/Library/Application Support/Microsoft/Teams, delete everything, restart. This is the “have you tried turning it off and on again” of Teams troubleshooting. On the new Teams client (Teams 2.0), this folder barely exists anymore. Teams moved to a containerized architecture under ~/Library/Containers/com.microsoft.teams2/. I deleted the Data folder inside every Teams container. Nothing changed.
Keychain Access cleanup.
The next level up. Open Keychain Access, search for “Microsoft,” delete everything. I removed entries for Microsoft Teams Identities Cache, ADAL tokens, Office credentials, the works. Restarted. The accounts were still there. It’s like they were stored in the walls of my apartment.
Round 2: Going Deeper
The SQLite approach.
This is where things got interesting. Instead of using Keychain Access, I went directly into the keychain database file with SQLite:
bash
KEYCHAIN_DB=$(find ~/Library/Keychains -name "keychain-2.db" 2>/dev/null | head -n1)
sqlite3 "$KEYCHAIN_DB" "DELETE FROM genp WHERE agrp LIKE '%microsoft%';"
sqlite3 "$KEYCHAIN_DB" "DELETE FROM inet WHERE agrp LIKE '%microsoft%';"I confirmed the rows were deleted. Ran a SELECT query. Zero results. Restarted. Opened Teams. The accounts were back. The database had been repopulated. By what? By whom? At this point I was questioning reality.
Hunting the MicrosoftRegistrationDB.
Using grep to search my entire ~/Library for the email addresses, I found them hiding in:
~/Library/Group Containers/UBF8T346G9.Office/MicrosoftRegistrationDB/This is a shared identity database that all Microsoft Office apps read from. It’s not documented anywhere in Microsoft’s official troubleshooting guides. I deleted it. Restarted. Still there.
The HTTPStorages discovery.
Another grep hit:
~/Library/HTTPStorages/com.microsoft.OneDrive/httpstorages.sqlite-wal
~/Library/HTTPStorages/com.microsoft.SharePoint-mac/httpstorages.sqlite-walOneDrive and SharePoint were caching the account identities in their HTTP storage databases. Deleted those too. Still. There.
Round 3: Nuclear Options
Full uninstall and reinstall.
I ran brew uninstall --cask microsoft-office microsoft-teams, then systematically deleted:
- Every
~/Library/Group Containers/UBF8T346G9.*folder - Every
~/Library/Containers/com.microsoft.*Data folder ~/Library/Application Support/Microsoft~/Library/Caches/com.microsoft.*~/Library/Preferences/com.microsoft.*- All Microsoft keychain entries (again)
- All Microsoft browser cookies from Chrome and Brave
Reinstalled Teams fresh. Opened it. The two ghost accounts were sitting there on the welcome screen like they owned the place. I seriously considered just throwing the laptop into the ocean.
Browser profile deletion.
A breakthrough came when I realized: the one account that DID disappear (a********@no*******tern.edu) was one I had never logged into from a browser on this machine. The two surviving accounts had active Chrome browser sessions. I deleted the Chrome profile for the XYZ account. Cleared all Microsoft cookies from both Chrome and Brave. Still didn’t fix it.
Checking server-side.
Maybe Microsoft’s cloud was pushing the accounts back? I logged into myaccount.microsoft.com, no devices listed. Checked mysignins.microsoft.com nothing. The accounts weren’t being synced from the cloud. They were living somewhere on my machine, in a place I couldn’t find.
The Fix: What Actually Worked
After three hours, two AI assistants, and enough deleted files to make a forensic analyst weep, here’s what finally killed the ghost accounts.
The Root Cause
On macOS Sequoia, Apple’s Security Daemon (secd) aggressively protects the keychain. When you modify keychain entries via Terminal using sqlite3 or the security command, the daemon can silently restore them from its in-memory copy. Your deletions look successful, the SQL query returns no rows, but the daemon just writes everything back. The 2>/dev/null at the end of your commands hides any errors, so you never even know it failed.
This is why every Terminal-based fix fails on Sequoia. The OS is literally undoing your work behind your back.
The Actual Fix
Step 1: Open Keychain Access through its hidden Sequoia location.
Apple moved Keychain Access in macOS Sequoia. It’s no longer in /Applications/Utilities/. You need to navigate to:
/System/Library/CoreServices/Applications/Keychain Access.appOpen Finder, press Cmd + Shift + G, paste that path, and open the app.
Step 2: Delete EVERYTHING Microsoft from all keychains.
In Keychain Access, search for each of these terms one at a time:
adalcacheoneauthteamsmicrosoftoffice
For each search, delete every entry that appears. Critically: click through ALL keychains in the left sidebar — “login,” “System,” and especially “Local Items.” The Local Items keychain is the one that Terminal commands can’t touch on Sequoia. That’s where the ghosts live.
Step 3: Reopen Teams.
That’s it. When Teams launches, it finds a genuinely empty identity store — not one that secd is about to repopulate — and shows you a clean sign-in screen.
No cached accounts. No ghosts. Just a fresh “Sign in” button.
Why This Bug Exists
Let me put on my product manager hat for a second, because this is a fascinating case study in how good architectural decisions create terrible user experiences.
Microsoft’s new Teams client shares an authentication layer across all Microsoft apps on macOS. When you sign into Word, Outlook, OneDrive, or Teams, they all write to the same identity store the OneAuth framework. This is genuinely good design. You sign in once, and everything works.
The problem is the exit path. Microsoft built an incredibly robust system for getting your identity INTO the cache, with multiple redundant storage locations (Keychain, Group Containers, MicrosoftRegistrationDB, OneAuth containers, WKWebView state, HTTPStorages). But they built essentially zero infrastructure for getting it OUT. Signing out of Teams removes the active session token, but it doesn’t touch any of the underlying identity caches.
On top of that, macOS Sequoia added aggressive keychain protection that breaks the one backdoor power users had direct database manipulation via Terminal. So now you have an identity that’s stored in six places, can’t be removed by signing out, and can’t be removed by Terminal commands. The only tool that works is the GUI Keychain Access app, which most troubleshooting guides don’t even mention because it used to be redundant with Terminal commands.
It’s a perfect storm of Microsoft’s architectural decisions and Apple’s security changes creating a bug that neither company considers their responsibility to fix.
The Quick Reference Guide
For anyone who just wants the fix without the three-hour backstory:
The Problem: Old accounts appear on the Microsoft Teams “Pick an account” sign-in screen on macOS and cannot be removed.
The Fix (macOS Sequoia / 15.x):
- Quit Teams and all other Microsoft apps.
- Open Finder →
Cmd + Shift + G→ paste/System/Library/CoreServices/Applications/ - Open Keychain Access.
- Search for:
adalcache,oneauth,teams,microsoft,office— delete every entry found. - Check all keychains in the left sidebar, especially Local Items.
- Reopen Teams.
Why Terminal commands don’t work: macOS Sequoia’s Security Daemon (secd) protects keychain entries in memory and silently restores them after Terminal-based deletions.
Final Thoughts
I’ve architected ticketing systems, and reverse-engineered eBay’s auction algorithms. But removing two email addresses from a Microsoft Teams sign-in screen? That took me three hours and required attacking a SQLite database inside macOS’s keychain infrastructure.
If you’re reading this because you’ve been fighting the same ghost accounts, I hope this saved you from the same spiral. And if you’re a Microsoft engineer who somehow stumbled onto this post please, for the love of everything, add a “Remove account” button to that sign-in screen. It’s 2026. We shouldn’t need forensic database skills to sign out of a chat app.