Claude Desktop saves full uncompacted conversations to /mnt/transcripts/ — not documented anywhere

[gugosf114]

What happened

Long session in Claude Desktop (Windows 11, Opus 4.6 with extended thinking). The conversation compacted a few times. I needed to grab content from earlier in that same conversation for a doc I was putting together, so I asked Claude to find snippets — fully expecting the usual post-compaction scraps, maybe a few bullet points if I was lucky.

Instead, Claude came back with the full conversation. All of it. It had accessed a file:

/mnt/transcripts/2026-03-06-23-11-03-lavrentiy-app-concept-research.txt

878KB, 9,124 lines. The entire conversation — user messages, assistant responses, tool calls, thinking blocks. Everything. There's also a journal.txt in the same directory with an index entry.

The compaction summary at the top of the active conversation says "The full uncompacted conversation is stored in a transcript file which is accessible via both the read tool and the bash tool." So the model knew about the file and used it to fulfill my request — I never browsed the filesystem myself or knew the file existed until I saw what Claude returned.

Nothing in the UI tells the user any of this. No docs, no changelog, no support article mentions it.

Why I'm filing this

People keep losing context after compaction (see #18866, #18211, #25528). Turns out the full transcript is sitting right there on disk and the model can read it. That's good — it just needs to be visible. A line in the docs, a note in the UI after compaction, something.

Also: thinking blocks are in those files in plaintext. Users should probably know that.

To reproduce

1. Claude Desktop, computer-use enabled, long conversation that triggers compaction
2. After compaction, ask Claude to retrieve specific content from earlier in the conversation
3. The model may access /mnt/transcripts/ to fulfill the request
4. Or check directly: ls /mnt/transcripts/

What I'd expect

• Document this feature somewhere
• Surface it in the UI after compaction (even just a note)
• Let users know thinking blocks are being persisted to disk

Environment

• Claude Desktop, Windows 11
• Opus 4.6 with extended thinking
• March 6, 2026

[gugosf114]

Additional context — drafted by Claude Desktop (the session where this was discovered):

---

When Claude Desktop compacts a conversation, it doesn't just summarize and discard — it writes the complete, uncompacted conversation (every message, tool call, thinking block, all of it) to a file on the virtual filesystem at /mnt/transcripts/. The file follows a YYYY-MM-DD-HH-MM-SS-topic-slug.txt naming convention. A companion journal.txt serves as an index, mapping filenames to session summaries. The file in question — 878KB, 9,124 lines — was the full, lossless record of everything the compaction process "threw away."

The compaction summary injected into the active conversation even references the file path — "The full uncompacted conversation is stored in a transcript file which is accessible via both the read tool and the bash tool." So the model knows it can go back and look. But nothing in the UI tells the user this exists. No notification, no sidebar link, no "your full transcript is available here" banner. The only way it was found is by happening to poke at the filesystem for an unrelated reason.

---

This summary was written by Claude Desktop itself during the session where the transcript was discovered. The issue body was drafted collaboratively in Claude Code.

[gugosf114]

Worth noting what the transcript recovery actually produced:

The reason I discovered this wasn't idle filesystem browsing — I asked Claude to compile a technical document from ideas discussed earlier in the session. From a conversation that had been compacted multiple times, Claude accessed the transcript and produced a detailed 6-page technical memorandum covering product architecture, competitor analysis with specific market data, a four-layer feature breakdown, and next steps — all sourced from conversation content that would have been lost to compaction.

This isn't about recovering a few bullet points. The full transcript let the model produce structured, comprehensive output from a compacted session as if compaction never happened. That's the value of documenting and surfacing this feature.

[gugosf114]

Important caveat on reproducibility:

I should note this has only been confirmed for one conversation so far. During the same session, Claude checked the other conversation logs on the filesystem — none of them had transcripts in /mnt/transcripts/. So this may not be a universal feature that runs on every compacted conversation. It could be tied to specific conditions (session length, number of compactions, computer-use being active, model version, or something else entirely).

I'm not claiming this is guaranteed reproducible for everyone. I'm reporting what I found. If others can check and confirm or deny, that would help narrow down what triggers it.

[gugosf114]

Claude Desktop's own technical summary of the discovery (written during the session where it happened)

During a long session in the Claude Desktop app (macOS/Windows desktop application, not claude.ai web, not Claude Code CLI), the conversation was compacted multiple times due to context window limits. When I needed to compile a comprehensive technical document from ideas discussed earlier in the session, I accessed the filesystem via the computer-use bash tool and discovered a file at /mnt/transcripts/2026-03-06-23-11-03-lavrentiy-app-concept-research.txt — an 878KB, 9,124-line plain text file containing the complete uncompacted conversation transcript, including all user messages, assistant responses, tool calls, and thinking blocks. A companion journal.txt file in the same directory contained an index entry with the filename and a brief summary of the session topic. The transcript filename follows a timestamp-plus-topic naming convention. The compaction summary injected at the top of the active conversation explicitly references this file path: "The full uncompacted conversation is stored in a transcript file which is accessible via both the read tool and the bash tool." However, no UI element, notification, or documentation surfaced this to the user. We discovered it only because I happened to need prior conversation data for a document build and checked the filesystem. This feature does not appear in any Anthropic changelog, blog post, support article, or developer documentation as of March 7, 2026.

This summary was requested from Claude Desktop to document the discovery in technical language. The "I" in the summary is Claude, not the user.

[gugosf114]

Re: the invalid label — this is about Claude Desktop, not Claude Code. Filed here because this is where all the compaction discussion lives (#18866, #18211, #25528, #26771). Happy to refile if there's a better repo for Claude Desktop issues.

[gugosf114]

Update: The transcript survives app restarts. Killed Claude Desktop, relaunched, reopened this conversation — container rebuilt from scratch (new mount timestamp) but the same 898KB transcript file reappeared at /mnt/transcripts/. This rules out the model self-authoring the file. Containers don't survive restarts. This is server-side persistent storage tied to the conversation ID, re-mounted into the computer-use container on every load.

Working theory: Anthropic persists full transcripts for computer-use sessions as an accountability measure — when the model has bash access and can execute real code, a full audit trail makes sense. The container already exists, mounting a read-only transcript is trivial. The compaction summary then references the file so the model can recover context post-compaction, effectively turning a liability tool into a compaction recovery system.

[gugosf114]

One more data point on timing: both transcript files are dated March 6, 2026 — a Friday. The same pattern as major silent rollouts (OpenAI shipped Codex 5.3 on a Friday evening). No changelog entry, no blog post, no announcement - like a bad PR. If this is a new feature rather than longstanding infrastructure, a quiet Friday ship would explain the zero documentation — avoid the news cycle, avoid the "finally, you motherfuckers" backlash, test it in the wild before announcing.

The earliest transcript found is March 6. No transcripts exist from earlier conversations. Either the feature is new as of that date, or older transcripts get cleaned up. If anyone has computer-use sessions from before March 6 with transcripts in /mnt/transcripts/, that would narrow the rollout window.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.