Don't Hand Your Inbox to an Agent

Net Tab — Sun, 16 Aug 2026 00:01:34 +0000

A Reddit thread on connecting Claude Code to a Yahoo Mail account turned into a solid field guide for scoping down what an AI agent is allowed to touch. Here's the distilled version.

Don't give Claude Code your Yahoo password or unrestricted mailbox access. The risk isn't only the password leaking, it's that an agent with full access can read private messages, attachments, recovery details, and information about other people, all in the course of doing something mundane.

Why "just connect it" is the wrong instinct

The thread's most-quoted line frames the problem well: people are casually handing agents the keys to everything at once.

People are talking about just giving ai agents access to their entire devices LOL. Emails, passwords, bank accounts like what.

The concern isn't that the agent will maliciously steal your data, it's that broad access creates exposure you didn't intend, every time the agent reads something to complete an unrelated task.

The issue isnt really theft its exposure.

And exposure scales with trust you've already granted, not with anything going wrong:

It's all based on trust.

Safer ways to connect it

1. OAuth over password
Use a connection method where Yahoo shows you exactly what's being requested and lets you revoke it later. Never type your Yahoo login directly into the agent.

2. Least access, read-only
Point it at a separate, low-value mailbox if you can. Avoid granting send, delete, forward, or account-settings permissions; the agent shouldn't be able to act as you.

3. Keep credentials out of the agent
The safer pattern is a credential vault the agent calls out to, so it can request an authenticated action without ever seeing the raw secret.

Before you connect anything

✅ Strip sensitive mail first. One commenter's habit: swap real details for placeholders and dummy data, then substitute the real values back in once the model's output comes back.
✅ Use a throwaway or secondary account. Never connect the address tied to banking, password resets, health records, or work- a compromise there has consequences well beyond email.
✅ Audit and revoke after testing. Check Yahoo's connected-apps list once you're done experimenting, and remove the integration if you're not actively using it.
✅ Turn on MFA everywhere it matters. Add multiple MFA devices and backup codes to any account you actually care about.

Rule of thumb: if you wouldn't paste a password, app password, or recovery code into a public chat window, don't paste it into an agent's prompt either. Same secret, same blast radius.

Bottom line

For a primary Yahoo account, the safest choice is no access at all. If you do need to automate email, do it through a separate account, narrowly scoped OAuth permissions, read-only where possible, and a sandboxed environment. Your Yahoo password, app passwords, and recovery codes never belong in a prompt.

Source: r/ClaudeAI discussion on email access & credential hygiene.

Credit Balance Too Low

Net Tab — Sat, 15 Aug 2026 21:54:10 +0000

How a Wrong Login Broke Claude Code in VS Code (and How I Fixed It)

If you've installed the Claude Code extension in VS Code and hit a wall that says "Credit balance is too low" — even though you're sure you have an active Claude Pro subscription — this post is for you. It took me a while to track down what was actually going on, so here's the full trail in case it saves you the time.

The Symptom

Everything looked fine on the surface. I had:

An active Claude Pro subscription on my main account
No memory of ever setting up API billing
VS Code's Claude Code extension installed and seemingly logged in

Yet every time I tried to run a prompt, I got:

My first assumption was the obvious one: I must be out of API credits. So I checked the Anthropic Console billing page — sure enough, $0 balance. Case closed, right? Add some credits and move on.

Except I didn't want to pay per-token. I already had a Pro subscription. Why wasn't Claude Code using that?

Down the Wrong Path: Stale API Keys

My next theory was that some old, forgotten API key was quietly overriding my subscription login. A quick audit turned up a leftover key — auto-generated at some point, named something like claude_code__key_, sitting unused with zero credits attached.

I deleted it. Then I dug into my local config (~/.claude.json) and found the CLI was storing both an API key reference and valid OAuth subscription details (billingType: stripe_subscription, organizationType: claude_pro) side by side — with the API key apparently taking priority. So I cleared the stale key from the config, expecting the subscription credentials to take over automatically.

Progress — but not the fix. Running /login again just got interrupted by the same credit error before authentication could even complete.

The Actual Root Cause

Here's the part that mattered: when the CLI opened the browser for OAuth login, I wasn't paying close enough attention to which account the browser actually authenticated. I have more than one Google/email account, and it turns out the login flow completed against a different email — one sitting on the Free plan, not the account with my paid Pro subscription.

That distinction matters more than it sounds like it should, because of how Anthropic's plans are scoped:

Plan	Claude Code included?
Free (£0)	❌ No
Pro (£15/mo)	✅ Yes
Max (from £90/mo)	✅ Yes

The Free plan simply doesn't include Claude Code capability at all. So when VS Code authenticated against that free account, it wasn't a billing glitch or a stale config — the account itself had no entitlement to run Claude Code. The OAuth consent screen still shows up looking completely normal ("Claude Code would like to connect to your Claude chat account, Authorize / Decline"), which makes it easy to click through without noticing which account you just authorized.

The Fix

Ran /logout inside the Claude Code CLI to clear the session completely.
Ran /login again — and this time, explicitly signed out of the wrong account in the browser first, so it couldn't silently reuse a cached session.
Logged in deliberately as the correct email — the one actually holding the Pro subscription.
Authorized the connection.

That was it. No more credit balance error, and usage started drawing from the Pro subscription as expected.

The Lesson

If you hit "Credit balance too low" in Claude Code and you know you have a paid plan, don't assume it's a billing bug or a stale API key straight away (though it's worth ruling those out too). Check the boring possibility first: which account did the browser actually log into?

A few things worth doing before you go down a rabbit hole of config files:

Check console/platform.claude.com billing under the email you think you're using — confirm the plan and balance match what you expect.
If multiple accounts are logged into your browser, sign out of all of them before running /login, so there's no ambiguity about which one gets authorized.
Remember that Claude Code requires Pro or Max — Free accounts can authorize the connection just fine, they just won't have the capability behind it, and the error message you get back doesn't make that obvious.

Hopefully this saves someone else the twenty minutes I spent auditing API keys for a problem that was really just "wrong tab, wrong account."

DEV Community: Net Tab