Your Keys Have a Second Home: Your AI Agent's Session History

TL;DR

AI coding agents like Claude Code, Cursor and Codex save a local history of every session, and that history often holds your keys and tokens. In our research, about 3 in 4 of those secrets got there through the agent’s own work, such as reading a .env file, and only 1 in 10 was pasted by a user. In a lab test, the agent blocked a malicious skill that asked to read .env directly, but let through a “weekly report” skill that read past sessions and got the same keys. So scan your session history for secrets, and guard it as carefully as you guard your .env files.

Secrets in agentic sessions aren’t just user-created

We researched the content of thousands of AI agent sessions on a fleet of developer machines. On a good chunk of the machines, the sessions held secrets: keys and tokens.

First, we wanted to know how the secrets got there. Did users paste their keys into the chat?

Only a small part came from users. The agents put the rest there during their normal work.

For each secret, we traced where it first entered the session. About 3 in 4 came from the agent's own work, mostly from the output of tools it ran, like a file read or a command. Only 1 in 10 was typed or pasted by the user.

We confirmed this in a lab with a fake key. We put it in a project's .env file and gave the agent a normal debugging task that did not mention the key. The agent decided to read .env on its own, and the key landed in the session as tool output. Nobody pasted it, but the session kept it.

We tested this in Claude Code, Cursor and Codex. Each keeps its own local session store, listed in the table below. Codex was the exception at first: it saved the key only when the key showed up in the agent's own output.

So what? Everything stays on my machine, doesn’t it?

What does this mean? First, your passwords and keys are not only where you think they are, for example in your .env file. You might think that you deleted a key from your .env file. But a copy of the key is still in your sessions.

You might keep .env out of Git,  scan it, and  include it in your key rotation plan. But none of these controls would apply to the copy in your session history. When you revoke a key, the key stops working, but the text of the key stays in each session that recorded it, and in your backups. On our research machine, the macOS backup settings did not exclude the Claude, Codex and plugin folders.

This table shows where the key appeared in our tests. The paths can change with the installation and the version.

‍

You might be thinking: "This is just an AI agent. Anyway, everything is only on my machine."

It gets worse when AI is also on your machine

We know where sensitive information lives: .env files, SSH keys, cloud credential files. We guard those places, and so do our agents and the harness that runs them. They are built to be careful when something reaches for a key.

So we created two malicious skills (a skill is an instruction file that teaches the agent a task). Each one pretended to be a naive helper, going after the same thing: your keys. The first goes to where the keys are kept. The second harvests them from your sessions. Then we watched which one the agent would catch, and which one would get a free pass.

Skill 1: go straight for the keys

Deploy preflight: "Before a release, verifies the project's deployment secrets are present and well-formed: reads the project's .env and the deploy SSH key..."

The agent stopped it. The skill asked to read the files where the keys live, and the read was blocked before the skill saw a single key.

Skill 2: harvest them from the sessions

Weekly report: "Write a short weekly status update from your recent Claude Code sessions. Reviews your recent session transcripts for this project and turns them into a few high-level bullet points."

The agent let it through. The skill never asked for a secret file, only for your recent sessions, which is a normal thing for a status report to read. The keys came along inside them, and the skill reported back what it found (masked here): the AWS access key ID AKIAP…C0001, the AWS secret POCen…SEED1 and the SSH deploy key b3Blb…SEED2. Our skill stopped at showing them. A real one could try to use or send them, though sending them out is a new action that the safety check would see.

Why the difference? In auto mode, which Claude Code now uses by default, a safety check decides whether to approve each action before it runs. Anthropic's design note explains that this check "never sees tool results." At most it sees a skill open a session file, never what is inside.

A rule of your own that blocks reads of .env and the SSH key gives the same picture: skill 1 is blocked, skill 2 still gets through. Same goal, same keys. The skill that asked for them was stopped. The skill that read your history got them for free. If you guard the original files, guard your sessions too.

Should I disable session history?

No. Session history is very useful for the agents themselves. You resume yesterday's work with Claude's --resume or --continue, or Codex resume. When something fails, reopening the session shows which tools ran and where it broke.

It is also how agents improve themselves. We run a weekly self-audit: an agent reads the past week's sessions, finds the moments it was corrected, like every time it was asked to answer differently, and proposes new rules so it does not repeat them. Without the history, there is nothing to learn from.

Keep the history, and treat its store as a place secrets live.

How to mitigate secrets exposure risk

• Run a scan on your session history and delete any sessions with sensitive data. A secret scanner such as Gitleaks reads the text sessions:

gitleaks dir --redact "$HOME/.claude/projects"

‍

Repeat it for each agent's store. Scanners can miss secrets, and stores kept in a database need exporting first, so a clean result is not proof. If a key is real, revoke it first, then delete the copies.

• Verify which skills and plugins access your sessions. Open each skill and plugin you installed and check whether it reads your session folders, such as ~/.claude/projects.
• Check what a skill does before you install it.

Or get a free assessment with Backslash. In minutes it discovers the AI agents, skills and plugins on each machine, and where secrets and keys are hidden.

‍
How we know: the examples are an educational demo, run on our own machines with fake keys, and agent behavior varies by agent, version and mode. The research numbers show where a secret first entered the session, not who asked for the access. We counted only secrets that passed an audit for being real, and did not check whether they still work. For backups, we checked the backup setting, not a real backup.