Where coding agents write on diskA field reference for the top six agents and the files they leave behind.

This is a lookup table, not an essay. If you came here to find out where Claude Code stores its OAuth token, jump to the Claude Code section. If you want to know which file Cursor writes when you accept an MCP grant, jump to Cursor. The closing section is the only opinion piece.

Two things changed how much this matters. In April 2026, Knostic and others documented that settings.local.json (Claude Code's per-project config) was getting bundled into published npm packages because the file lived inside the repo and no default .npmignore excluded it. Roughly 1-in-13 packages on the registry shipped with one. The fix was a single ignore line, but most people never wrote it because they did not know the file existed.

The second thing: Cursor and Cline added MCP support across the winter, which moved another category of "secrets-adjacent state" out of a single agent's settings and into a shared format. Knowing where each agent writes is no longer optional if you handle production credentials on the same laptop where you run an agent.

How to read this reference

Every entry below uses three buckets:

• User-scoped: under $HOME, follows the user across projects. Tokens, telemetry preferences, default model.
• Project-scoped: inside or beside a repo. Tool grants, MCP server list, project-specific overrides. This is the bucket that leaks.
• Volatile: logs, chat history, crash reports, MCP traces. Rotates or grows without bound, depending on the agent.

Paths assume macOS or Linux defaults. Windows paths differ; check each vendor's docs. Where an environment variable controls the path (XDG_CONFIG_HOME, CLAUDE_HOME, etc.), the variable is noted.

Claude Code (Anthropic)

Bundle of files the Claude Code CLI writes on a normal install. Verified against the public docs and the April 2026 Knostic disclosure.

If you publish anything from a Claude Code project, add .claude/settings.local.json to .npmignore, .gitignore, and your files: allowlist in package.json. Use the most restrictive of the three.

The Check Point write-up of CVE-2025-59536 also confirmed that a crafted .claude/CLAUDE.md could trigger command injection in older releases. Upgrade to a current Claude Code build; the fix shipped in 2026-Q1. See yesterday's audit guide for the broader pattern.

Cursor

Cursor stores per-user state in a VS Code-style directory and project state alongside the repo. The exact paths shifted twice in 2026; the table below reflects the May 2026 release.

Per the Knostic research, Cursor's .cursor/ directory has been observed in published npm tarballs with the same frequency pattern as Claude Code's .claude/. Same fix: add to .npmignore.

Codex CLI (OpenAI)

OpenAI's Codex CLI is more recent and writes less than the GUI-class agents. The footprint as of May 2026:

The history.jsonl file is the one most people miss. It accumulates everything you typed at the prompt. If you ever pasted a key into the agent (you shouldn't, but people do), the value is sitting in plaintext on disk until you truncate the file.

Aider

Aider is the most filesystem-honest of the bunch: nearly everything is project-scoped and visible.

Aider's history files have surfaced in repo scans before; trufflehog has flagged them as a category. The fix is the global .gitignore line, not anything Aider-specific.

Cline (VS Code extension)

Cline lives inside VS Code, which means most of its state ends up in VS Code's extension storage.

Cline's SQLite store has been flagged by at least two laptop-audit scripts in circulation as the single highest-value file on a developer's machine, because it concentrates credentials for every provider you've ever connected. Treat it like a vault; back it up only into something encrypted; rotate any provider key whose only home is this file.

Continue (VS Code / JetBrains extension)

Continue is configuration-heavy and stores its main file in a predictable location.

~/.continue/config.json is the canonical "I left a key in plaintext" file in 2026 leak data. If you used the quickstart and pasted a provider key, it lives here, unencrypted, until you move it to an env var or a broker.

The five categories that have leaked

Across the six agents, the same five file categories show up in every incident write-up. If you're triaging a single laptop, these are the buckets to grep for:

1. Project settings with tool grants (.claude/settings.local.json, .cursor/, .codex/). These leak via npm, pypi, and any other package registry that defaults to "publish the whole working dir."
2. History files (history.jsonl, .aider.chat.history.md, Continue's session JSONL). These leak via git accidentally adding the file, or via a teammate's grep when the laptop is shared.
3. Provider key stores (Cline's SQLite, Continue's config.json, raw ~/.codex/auth.json). These leak via backups, sync tools, and "I'll just copy my dotfiles to the new machine" rituals.
4. MCP server configs. The lists encode which third-party tool servers you trust. A leaked list is a target list for an attacker.
5. Logs. Less catastrophic than tokens, but the trace of which tools you ran on which files is itself sensitive.

GitGuardian's 2026 Sprawl report measured AI-coding repos as 40% more likely to leak than the corpus median. The category that drove the delta was project-scoped agent settings, not the more famous .env.

A repo-level allowlist worth copying

This is the minimum .gitignore (and equivalent .npmignore, .dockerignore) that catches the project-scoped files for all six agents. Add the lines that apply to the agents your team uses:

# AI coding agents — project-scoped state
.claude/settings.local.json
.claude/projects/
.cursor/
.codex/
.aider.conf.yml
.aider.input.history
.aider.chat.history.md
.aider.tags.cache.v*/
.cline/
.continue/

# History files that creep in
**/history.jsonl
**/*.chat.history.md

Run git check-ignore -v <file> on a representative path from each agent you use to confirm the rule fires. Add a CI step that fails the build if any of these paths shows up in the diff; the scan-repo-for-leaked-secrets guide covers the pattern in more detail.

For npm, prefer the files: allowlist in package.json over .npmignore. Allowlists are safer than denylists when a new agent's directory appears between releases.

A user-level audit script worth running quarterly

Run this on your laptop once a quarter. It enumerates every agent's user-scoped directory, prints permissions, and flags world- or group-readable files. Not exhaustive; useful as a starting point.

for dir in \
  ~/.claude \
  ~/.codex \
  ~/.aider \
  ~/.continue \
  ~/.config/Cursor \
  ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev \
  "$HOME/Library/Application Support/Cursor" \
  "$HOME/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev"; do
  [ -d "$dir" ] && find "$dir" -type f -perm -004 -ls 2>/dev/null
done

A clean output is good. A list of paths means an agent wrote a file the rest of your system can read; check whether it contains a token.

What this means for your stack

The minimum action is to add the project-scoped lines from the gitignore block above to every active repo this week, then run git rm --cached on anything that's already tracked. That single change closes the category that produced most of the published-package leaks across 2026. The user-level audit is once-a-quarter work; calendar it.

The architectural pattern that closes the rest of the gap is to stop putting raw provider keys in any of these files. A runtime broker holds the value, hands the agent's child process an env var only for the brokered run, and writes nothing the agent can later cache. That way a leaked Cline SQLite or a leaked ~/.continue/config.json does not contain a usable credential, because no usable credential was ever written there.

hasp is one working implementation. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, then connect the agent you use. The user-scoped paths in this reference still get created (Claude Code still writes ~/.claude/), but the value the agent sees at runtime is brokered, and the file you forget to gitignore does not contain a credential. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

Whether you ever install a broker, the reference is the same. Every agent writes more than its docs imply. Knowing the paths is the prerequisite for every audit, every gitignore, and every "did this leak" answer. Bookmark this page; the table is the whole point.