Warp's CEO, Zach Lloyd, estimates that "roughly 1% of Warp users may have been impacted" after attackers went through a third-party vendor in Warp's infrastructure and reached agent decision logs and user telemetry (BleepingComputer, October 27).

Whatever was in Warp's logs, you can inspect the agent traces already sitting on your own machine. A Claude Code transcript holds the prompts you typed, the commands the agent ran, what those commands printed, and the contents of the files it read.

Open one with jq and grep and two of the risks the Cloud Security Alliance drew out of the incident get concrete: what a trace contains, and where copies of it live.

What Warp said, and what it hasn't

Lloyd described "an active and narrow-banded exploitation of a vendor in Warp's infrastructure" that Warp became aware of on a Friday, and said "we detected the operation within hours and were able to remediate and mitigate the impact" (BleepingComputer). BleepingComputer adds that analysis of the incident suggests the attack was powered by "an agent swarm." Warp brought in CrowdStrike, told law enforcement, and notified the users it identified as affected.

Warp has not named the vendor. It has not said whether the exposed logs held source code, prompts or credentials. The CSA research note, dated October 28, says so plainly, and pairs Warp with the OpenCode key exposure ten days earlier. So nobody outside Warp knows what was in those particular logs.

What the CSA does say is general: agent traces hold "traces of prompts, reasoning steps, tool calls, command output, and file contents," and one trace can combine source code fragments, infrastructure details and secrets. The commands below check that claim against your own files.

Open one of your own traces

Claude Code keeps every session as a JSONL file. Its data usage docs say transcripts are stored "locally in plaintext under ~/.claude/projects/ for 30 days by default." The .claude directory reference is blunter: "Anything that passes through a tool is written to a transcript on disk: file contents, command output, pasted text." The same page adds the system prompt, tool definitions, request parameters and the CLAUDE.md files it loaded.

Anthropic doesn't publish a schema for these lines, so treat the field names below as what current versions write, and check them against your own file. Start with the newest session and count what kinds of lines it holds:

# newest Claude Code transcript on this machine F=$(ls -t ~/.claude/projects/*/*.jsonl | head -1) jq -r '.type // "none"' "$F" | sort | uniq -c

Each assistant message carries content blocks, and tool calls are blocks of type tool_use with a name and an input. List which tools ran, and how often:

jq -r '.message.content[]? | objects | select(.type == "tool_use") | .name' "$F" \ | sort | uniq -c | sort -rn

An unrolled paper scroll coming out of a laptop, each line marked with a small icon for a prompt, a tool call, a terminal and a document, with a magnifier over one line showing a small orange key
One session transcript, line by line: prompts, tool calls, command output, file contents, and now and then a key.

Pull out the parts an attacker would want. Every shell command the agent ran, and every file it opened:

# every shell command the agent ran jq -r '.message.content[]? | objects | select(.type == "tool_use" and .name == "Bash") | .input.command' "$F" # every file it opened with Read jq -r '.message.content[]? | objects | select(.type == "tool_use" and .name == "Read") | .input.file_path' "$F" | sort -u

The commands show your hostnames, database names, deploy scripts and the flags you pass them. The file list maps your repo. Then look at the size of what came back, which sits in tool_result blocks:

jq -r '.message.content[]? | objects | select(.type == "tool_result") | .content | tostring | length' "$F" \ | awk '{s+=$1} END {print s " chars of tool output"}'

That number is mostly your code and your command output, copied verbatim. A trace is a partial snapshot of your repository plus a log of how you operate it.

The secrets check

The docs spell out the uncomfortable part: "If a tool reads a .env file or a command prints a credential, that value is written to projects/<project>/<session>.jsonl," and "Transcripts and history are not encrypted at rest. OS file permissions are the only protection" (.claude directory reference).

Count matches for a few common key formats across every transcript, without printing the values. The -r matters: it also covers subagent transcripts and the large tool outputs Claude Code stores in each session's tool-results/ folder (.claude directory reference).

SK='(^|[^A-Za-z0-9])sk-[A-Za-z0-9_-]{20,}' P="$SK|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}" grep -rcE "$P" ~/.claude/projects | grep -v ':0$' grep -rcE '(PASSWORD|SECRET|TOKEN)=' ~/.claude/projects \ | grep -v ':0$'

grep -c counts matching lines per file, and one JSONL line can hold a whole file, so read each number as "lines with at least one hit" in that file. The sk- pattern needs a non-alphanumeric character in front, so words like task- or disk- don't trigger it. These patterns catch OpenAI-style, AWS access key and GitHub token formats only. The CSA note's warning applies to any tool doing this for you: "pattern-based redaction will not catch every secret."

Codex keeps its local state under CODEX_HOME, which defaults to ~/.codex, and by default saves local session transcripts there. The first command below lists what it wrote in the last day; the second runs the same check without assuming its file layout:

find ~/.codex -name '*.jsonl' -mtime -1 find ~/.codex -name '*.jsonl' -exec grep -lE "$P" {} +

If either check prints a file, treat that credential the way the CSA note does for the Warp case: rotate it at the source. "Deleting a key or log from a vendor console does not undo exposure."

Where copies of a trace live

The CSA's other point is about location. "Vendor-hosted agent services concentrate both credentials and context outside the customer's boundary," so one supplier breach exposes many customers at once. A trace you never think about can exist in several places:

  • Your disk. ~/.claude/projects/ for 30 days by default, and ~/.claude/history.jsonl, the prompts you've typed with their project path, which is kept until you delete it (docs). Plus whatever backs up your home directory.
  • The model provider. For commercial Claude Code accounts, Anthropic's standard retention is 30 days. Consumer accounts that allow training are retained for 5 years (data usage).
  • Feedback paths. Transcripts sent through /feedback, /bug or /share are retained for 5 years. A transcript shared from the session survey is kept up to 6 months, with known key patterns redacted and "source code, file contents, and other conversation content" uploaded as-is (data usage).
  • Tool vendors. Any terminal, IDE or wrapper that sends agent data to its own servers. Warp's privacy page says its "Configurable Secret Redaction is disabled by default," and that on Business and Enterprise plans, under its zero data retention agreement, "no AI interaction or console data is ever collected."
  • Your own observability stack, if you export agent telemetry to it.

Claude Code's usage metrics, for comparison, "never include your code, prompts, or file paths" (data usage). Metrics and traces are different animals, and the CSA's advice is to file traces as "confidential engineering data," not product telemetry.

One glowing document at the center with thin lines running to a laptop folder, a cloud, a server rack with a cracked door, a backup drive and a git branch
One agent trace, many copies. The breach only needs the weakest one.

You can shrink the local side. Shorten retention and keep credential files out of reads in ~/.claude/settings.json:

{ "cleanupPeriodDays": 7, "permissions": { "deny": ["Read(./.env)", "Read(./.env.*)"] } }

A deny rule on Read doesn't cover every way a command can print a file, so treat it as one layer. Then clear old state for a project you're done with. claude purge prints the plan first, and --dry-run deletes nothing:

claude purge ~/code/app --dry-run

For Codex, the config docs turn off local history persistence with:

[history] persistence = "none"

Claude Code's closest switch is the CLAUDE_CODE_SKIP_PROMPT_HISTORY environment variable, which skips writing transcripts and prompt history (docs). With no transcript on disk, resume and rewind have nothing to work with for those sessions, so decide per project.

Where Hermes sits

I build Hermes IDE, so weigh this section with that in mind. Hermes runs each agent's own CLI in a real terminal, with the agent's own sign-in, and never asks for your tokens. Claude Code inside Hermes still writes its transcript to ~/.claude/projects/ and still sends your prompts to Anthropic. Hermes doesn't change that path, and it doesn't redact the agent's transcript.

Hermes's own copies stay on your disk. Its Rust backend owns the terminals, git and local persistence (README). It saves every agent turn so you can diff or restore one, and those turn snapshots are file contents too, so they belong in your inventory. Per the 2.2.9 notes, snapshots from worktree tasks are removed from the repository 14 days after the session closes, and saved output of sessions closed more than a month ago is cleaned up.

The Hermes Review Desk in By turn view for a Claude Code task in orders-api, listing two turns, the diff of src/db.ts from turn 1, the changed files and a drafted commit message
The Review Desk (⌘G) by turn: T1 changed 3 files (+69 −1) and T2 one file (+1 −0). The turn history behind it lives in your repository, on your disk.

On what leaves the machine: since 2.3.0, anonymous usage statistics are on by default, and the release notes say they "never include your code, prompts, file names or anything that identifies you," so they don't carry your traces to a Hermes server. You can turn them off in Settings > Privacy. Hermes also checks hermes-ide.com for news at most once a day, without cookies, and a setting switches that off. Since 2.3.2, terminal suggestions never offer a password, key or token back to you.

Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It isn't affiliated with Warp, Anthropic, OpenAI or Nous Research. Download it or read the code on GitHub.

Run the grep check above on your own machine tonight. How many of your transcripts had a hit?

If this was useful

An agent trace is the same object an LLM observability stack collects on purpose: prompts, tool calls, outputs, cost. Observability for LLM Applications covers how to trace LLM features in production, run evals and watch cost and quality, which includes deciding what a trace should hold and who gets to keep it.

Observability for LLM Applications — the book