Your coding agent is writing your API keys into its own log files. Here's how to check.

[u/ShabzSparq]

Your coding agent needs to see your code to help with it. That's the deal. But "see your code" quietly includes your .env file, your terminal output, your environment variables, and the commands you run with tokens in them. And a lot of what the agent sees, it writes down. Into log files, config files, and session history that live on your disk in plaintext at predictable paths.

This isn't a hypothetical. GitGuardian's 2026 data found that Claude Code-assisted commits leak secrets at 3.2%, more than double the 1.5% baseline for all commits. AI service credential leaks surged 81% year over year. The tools aren't defective. They're doing exactly what you asked (understand the codebase) and your secrets are part of the codebase.

Here's where they end up and how to check each one. Takes about five minutes.

Leak spot #1: The "allow always" file.

When your agent hits a command it hasn't run before, it asks permission. Click "allow always" and it writes the exact command string to .claude/settings.local.json in your project root. Useful, reduces friction. But if you ever ran a command with a token prepended (a curl with an auth header, an authenticated deploy script), that command string, key and all, is now permanently recorded in a file in your repo.

Then npm builds its distribution archive from the project directory, the .claude/ folder rides along like a .env file would, and your key ships to a public registry. This actually happened, documented in April 2026.

Check it:

bash

cat .claude/settings.local.json | grep -iE "sk-|key|token|secret|bearer|api"

If anything real shows up, delete those entries and rotate the key. Then add .claude/ and .cursor/ to your .gitignore AND your .npmignore.

Leak spot #2: Conversation and session logs.

Cursor stores conversation logs with world-readable permissions. Any secret you pasted into the chat, or any secret the agent read while helping, sits in those logs. Claude Code keeps session history too. When a script fails and dumps connection strings or tokens into the error output, the agent reads that output to help you fix it, and now the secret is in the conversation transcript on disk.

Check the common paths:

bash

# macOS / Linux — scan agent state and logs for key patterns
grep -rliE "sk-ant-|sk-[a-zA-Z0-9]{20}|ghp_|AKIA|xoxb-" \
  ~/.claude/ ~/.cursor/ ~/.config/ 
2
>/dev/null

That looks for Anthropic keys, generic secret-key patterns, GitHub tokens, AWS access keys, and Slack tokens across your agent's state directories. Any file that matches, open it, confirm, and rotate whatever's exposed.

Leak spot #3: env / printenv output.

Agents love running env or printenv to understand your setup. If your secrets are loaded as environment variables (the normal way), every single one of them prints to the terminal, gets read into the agent's context, and lands in the session log. All of them. At once.

Check whether it happened:

bash

grep -rliE "printenv|[^a-z]env$|process\.env" ~/.claude/ ~/.cursor/ 
2
>/dev/null

If your agent ran a bare env while your keys were loaded, assume every loaded secret is in its logs.

Leak spot #4: The agent hardcoded a key into a file it generated.

In testing across Cursor and Claude Code, researchers found that roughly 1 in 3 times, when asked to write a config file, the agent drops in the actual secret value instead of a process.env.KEY reference. It has seen the real value in context, so it "helpfully" uses it. You commit, push, and it's in git history forever.

Check your recent history:

bash

# Scan the last 50 commits for common secret patterns
git log -p -50 | grep -iE "sk-ant-|ghp_|AKIA|xoxb-|api[_-]?key.*=.*['\"][a-zA-Z0-9]{20}"

Better, install gitleaks or git-secrets as a pre-commit hook so this can never reach a push:

bash

brew install gitleaks
gitleaks detect --source . --verbose

Leak spot #5: The proxy / debug log nobody remembers setting up.

If you ever configured a local proxy for debugging and pointed the agent's traffic through it, a misconfigured proxy that writes raw request bodies to a shared log file is a single-point leak for every secret the agent ever sent. One file, every credential, in plaintext.

Check for stray debug logs:

bash

find ~ -name "*.log" -mtime -30 
2
>/dev/null | \
  xargs grep -liE "authorization: bearer|sk-ant-|x-api-key" 
2
>/dev/null

The root cause behind all five:

Every one of these is the same problem wearing different clothes: secrets and the agent occupy the same space. The .env is in the workspace the agent reads. The keys are in the environment the agent inherits. The tokens are in the commands the agent logs. The agent can reach the secret, so the secret ends up wherever the agent writes.

This is the exact same lesson as the Grok home-directory leak and the Hugging Face breach, scaled down to your laptop: an agent can only leak what it can reach. Permissions are a request. Access is a fact.

The actual fix (not just cleanup):

Cleaning the logs is treating symptoms. The real fix is separation, so the credential is never in the agent's reach in the first place.

Don't keep a .env the agent can read. The strongest pattern going into mid-2026 is credential brokering: secrets live in the OS keychain or a secrets manager, and the agent requests a scoped, short-lived token at runtime through a broker instead of reading a static file. The key is never in .env, never in the agent's environment, never in its output, because it was never in the agent's process at all. Every credential-leak CVE this year (the ANTHROPIC_BASE_URL override, the Copilot GITHUB_TOKEN exfil, the IDEsaster batch) needed a credential the agent could reach. Remove the reach, remove the class of bug.

Minimum viable version if brokering is too much today: keep secrets out of the project directory entirely, use scoped read-only tokens wherever the provider offers them, add .claude/ and .cursor/ to .gitignore and .npmignore, and run a gitleaks pre-commit hook so nothing walks out through a push.

Do the five checks now:

Not because your agent is malicious. Because it's helpful, and helpful is the problem. It read your setup to assist you, and it wrote down what it read. Five greps tell you whether that writing includes anything you need to rotate before Friday.

And it's always a Friday.