Getting Outlook.com into my homelab assistant (Gmail was easy, Outlook wasn't)

I wanted Claude Code on my home server to read and tidy my personal email. Gmail took about five minutes. Outlook.com took an afternoon and a small fight with Microsoft. Same goal, two very different roads, and the gap between them says a lot about how the two companies treat a normal person with a free account.

Gmail took five minutes

There's a ready connector for Gmail. I clicked connect, approved the consent screen, and Claude Code could read my mail. The OAuth handshake happened in the background and the tokens were handled for me. That was the whole job. It felt the way connecting two things should feel.

So I assumed Outlook would be about the same. It was not.

Outlook took an afternoon

The first wall is that Microsoft killed basic auth and app passwords for personal Outlook.com accounts. The old move, point a client at the server with a username and password over IMAP, just doesn't work anymore. And for a free Outlook.com account there's no turnkey connector like Gmail has either. If you want anything to read that inbox programmatically, you go through the door Microsoft actually supports now: OAuth2 and the Microsoft Graph API. The catch is that you build that part yourself.

What that meant in practice is that I had to register my own application in Azure. Not because I run a company tenant, just to read my own inbox. You create an app registration, set it to allow personal Microsoft accounts, mark it as a public client, and ask for delegated permissions: read and write to mail, plus offline access so it can refresh on its own instead of making me log in every hour. Then you do a device-code login once. It prints a short code, I paste it into a Microsoft page and approve, and the server walks away with a refresh token it can keep using. After that it quietly refreshes in the background and I never touch it.

The tool around it is small. One script handles the login and the silent refresh. Another wraps the handful of Graph calls I actually use: list the inbox, search, move a message, drop it in a category. Claude Code calls those. The refresh token lives on the box, locked down, never in someone else's cloud. A scheduled job runs twice a day, files receipts and bank mail into folders, junks the obvious promotions, fishes the occasional verification code back out of the junk pile, and pings me on Telegram only when it actually moved something.

The permission that cost me an hour

Not every Graph permission does what you'd guess. Read and write to mail lets me move and categorize messages all day, but it flatly refuses to create server-side rules. That needs a different permission and another round of consent, and until you add it the rules API just answers with a polite access-denied. So my filing logic runs as my own code on a schedule rather than as native Outlook rules living on Microsoft's side. It works, it just wasn't the plan I started with.

Why Gmail is easy and Outlook isn't

Google ships the smooth path. You click, you approve, you're in. Outlook.com on a personal account feels like an afterthought next to Microsoft's corporate 365 story, where an admin wires all of this up for the whole company. As a free-account user you get handed the raw API and a build-it-yourself afternoon. The technology is fine once it's running. The on-ramp is the tell, and it tells you who each platform is really built for.

If you've been fighting personal Outlook.com from a script or an agent and wondering why your IMAP password suddenly stopped working, that's why. Basic auth is gone for personal accounts. The supported route is your own Azure app registration, the Graph API, a one-time device-code login, and a refresh token you keep yourself. It's more work than Gmail by a mile, but it's a single afternoon, and once it's done anything on the box can read and sort that mailbox. Thanks for reading. Happy to compare notes in the comments if you're stuck on the same thing.