Most developers using Claude Code have a rough sense that their conversations go to Anthropic's servers. What they haven't thought through is exactly what "the conversation" includes — and how quickly it grows beyond what you typed.

What actually goes upstream

Every message in a session — including the contents of files read by tools — gets sent to Anthropic's API to generate a response. That means:

• A .env file Claude reads during a session puts those values in the API payload
• Terminal output containing tokens or keys lands in the context
• Every tool result — file reads, search results, MCP responses — is part of what gets sent

The context window is cumulative. A long session like a package audit or a refactor touches a lot of files. All of it goes.

Anthropic's data retention policies apply to that. Whether it's used for model training depends on your account type and opt-out status. It's not public — but it does leave your machine.

The three risk surfaces

1. Files Claude reads

The most direct one. If you ask Claude to look at a config file and it contains real credentials, those values are now in the session context. .env files are the obvious case. Less obvious: vercel.json, deployment scripts, anything with an inline API key.

Be conscious of what you're asking Claude to read. You don't need to be paranoid — just aware.

2. MCP scope

MCP servers run locally and make API calls on Claude's behalf. Claude sees the results, not the raw credentials. The risk is what the token is allowed to do.

Read-only is fine persistent. A read-only GSC integration can sit connected — worst case is Claude seeing your search data.

Write access is a different category. GTM with write scope can push tag changes to production. A miscommunication or misread instruction could result in a script firing incorrectly on a live site. Treat write-capable MCPs like a database migration: connect for the task, verify what happened, disconnect.

3. Prompt injection

When Claude calls an MCP tool, the results come back as content Claude processes. If that content contains something that looks like an instruction, Claude is designed to resist it — but it's not a guarantee. For read-only tools the stakes are low. For write-capable tools it's worth being conscious of, especially when the data source is external.

What about gh?

Safe by default. The GitHub CLI stores its OAuth token in macOS Keychain — not a plaintext file. Claude uses it for specific, visible tasks: create PR, watch CI, merge. The token never surfaces in the conversation.

One thing worth checking: your gh token scope. Standard repo + workflow is fine. If it includes admin:org or delete_repo, tighten it.

gh auth status  # shows your current scopes

The credential vault pattern

The cleanest long-term solution: credentials should never live in files Claude could read. The op CLI from 1Password does this with op run:

op run -- pnpm build

Secrets are injected from the vault as environment variables at runtime. They never touch disk. They never appear in a file. They never land in the API payload sent to Anthropic.

macOS Keychain via the security CLI is a lighter alternative for simpler setups.

This isn't urgent for a solo portfolio project. But if you're using Claude Code on client work or anything with real credentials, it's worth setting up.

The practical checklist

• Know what MCP servers you have connected and what scope each has
• Write-capable integrations: connect for the task, disconnect after
• Don't paste credentials directly into chat
• Be conscious when asking Claude to read config files
• Check gh auth status — scope should be repo + workflow only
• Rotate any credentials that may have been in session context when you're unsure

None of this requires paranoia. It just requires the same level of awareness you'd bring to sharing your screen on a video call — you'd close your .env before screensharing. Same principle.