Encrypted Reasoning Traces on Your Laptop: Resume or Strip

When you use Claude, GPT, or Gemini with thinking turned on, the lab hides the model's scratchpad. But it still hands you an encrypted copy of those notes so the next turn can continue, and people dump that copy into GitHub.

Public traces hid 315,320 encrypted reasoning blocks inside 6,708 posted agent sessions, according to a recent interesting research.

4.9% of those sessions (328) leaked at least one real secret from the hidden channel.

You must have seen that paper "Stealing Reasoning Traces from Proprietary LLM APIs" which says: The copy that still matters is the one on your disk.

"Resume and publish are two jobs, so they need two logs" means one log is the private copy you send back so the same model can continue, and the other is anything you share, which should not carry the encrypted field.

Keep the field only where you still have to continue your run on the same model, in a store you treat like a session cookie, with an expiry.

Strip it before git, eval dumps, support zips, screenshots, or a blog post.

I grepped my own Claude Code and Codex folders, which I use for research and content writing, to show that the field piles up even there.

Counts only. I did not read the blobs. (and you can run the same test)

What follows is the two-path rule, the 30-day vs no-cleanup vs six-year-export triangle, the AWS page that calls the field a hash, and what "patched" does not retire.

Why APIs hand you encrypted thinking

AI Labs consider the reasoning chain of their models as company secrets that rivals can use to train competitive models through distillation.

Therefore, whenever you send a request to their models, they encrypt the reasoning tokens and hand you a sealed blob because the next turn still needs that scratchpad and the server will not store it.

A hotel key card is the same shape: you cannot read the stripe, and the door will not open unless you present the same card.

But the same card opened more than one door. The paper's experiments imply the wrapping key was shared across conversations, and across cheaper sibling models in the same family, so a weaker model could open a stronger model's envelope.

Authors infer that from portability, and they did not extract the key.

Anthropic puts the sealed copy in a signature on each thinking block. Its docs call that field "an encrypted copy of the full reasoning that you pass back unchanged."

OpenAI puts it in encrypted_content on reasoning items. That field ships by default when store is false or the org is on Zero Data Retention, per OpenAI's reasoning guide.

Google uses thoughtSignature so Gemini can continue a tool loop without keeping that state on the server.

You round-trip the blob because some calls fail without it. Anthropic requires the prior thinking blocks inside a tool-use turn, recommends them across turns, and lets you omit them outside tool use.

Gemini 3 function-calling is stricter: drop the current-turn thought signature and the call can result in a "bad request" error (400).

So the envelope is required on resume and tool-use paths, and optional on a lot of other logs you still keep.

That August paper is why the bytes are a credential-class object. From 6,708 GitHub and Hugging Face trajectories the authors decoded 315,320 blocks.

Counting every source, including benchmarks, they recovered 367 personal-data artifacts and 182 credentials.

Genuine (non-benchmark) sessions produced 704 distinct artifacts, including 62 API keys, 33 passwords, 24 access tokens, 7 private keys, and 30 personal emails.

64 of those 704 lived only in the encrypted reasoning, so a pass over the visible chat would not have detected them.

A recurring trigger was "please sanitize this repo."

In the paper's example, a GPT-5.2 Codex agent asked to clean a repository before publishing restated live API keys in hidden reasoning while it stripped them from the files you can see.

The visible chat looked clean, and the envelope still listed an AWS secret and a Hugging Face token.