[BUG] # Cowork session content not rendering for chats created by older CLI versions — data confirmed intact via direct extraction

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Cowork session content not rendering for chats created by older CLI versions — data confirmed intact via direct extraction

Platform: Windows, Claude Desktop 1.49585.0 (41ad1d) (MSIX package Claude_pzs8sxrjxfjjc)
Affected sessions created by: Claude Code CLI 2.1.197 (per each session's own system/init record)
Relates to: #69663 (Cowork sessions missing from Recents — adjacent but distinct; see "Not the same as #69663" below)

Summary

Cowork projects/sessions that were created several weeks ago (originally by CLI 2.1.197, restored to this machine from a file-level backup after an unrelated local-cache deletion) show their correct title and metadata in the current Desktop app, but opening any of them displays no message content — empty chat view, as if the session had no history.

This is confirmed to be a rendering/parsing problem in the Desktop client, not data loss: the underlying audit.jsonl transcript files are fully intact, valid JSONL, and contain real user and assistant message text. I verified this independently by parsing the files directly in PowerShell and extracting readable transcripts — full details below.

What's ruled out

• Not missing or corrupted files. Every audit.jsonl for the affected sessions is present with correct byte sizes matching the original backup exactly (verified via robocopy copy report: 0 failed, 0 mismatch across 2133 files / 79.44 MB).
• Not the #69663 Recents-indexing bug. In that report, sessions were missing entirely from the Recents list. Here, the opposite: session names and metadata display correctly in the UI — they are indexed and linked to the right project. The failure is specifically that message content doesn't render once opened.
• Not the Cowork message-dispatch/IPC hang (a separate issue I reported previously, referencing #59532/#26805). That bug affects live, in-session message delivery mid-conversation. This bug affects loading historical content from disk into the UI — a different code path.
• Not a parsing failure at the JSON level. Every line in the affected files parses cleanly with standard JSON parsing (ConvertFrom-Json in PowerShell, no errors, no malformed lines encountered across 16 sessions).

Evidence

Each audit.jsonl is a JSON-Lines file with entries of type: user, assistant, system, result, rate_limit_event. A real user entry from an affected session:

{"type":"user","uuid":"f3b43b6f-...","session_id":"1fc25bd6-...","timestamp":"2026-07-03T01:32:11.483Z","message":{"role":"user","content":"read the files, the goal is to create a project team..."}, ...}

And a real assistant entry with rendered text content:

{"type":"assistant","message":{"model":"claude-sonnet-5","role":"assistant","content":[{"type":"text","text":"Now writing the consolidated CLAUDE.md."}]}, "session_id":"704e3ffa-...","timestamp":"2026-07-03T01:34:17.244Z", ...}

Both are well-formed and contain genuine conversation content. To confirm this wasn't a one-off, I wrote a short script that walks every local_<uuid>/audit.jsonl under the affected account folder, extracts user messages (plain string content) and assistant text blocks (content[].type == "text"), and writes a readable transcript per session. Result: all 16 sessions extracted successfully, with turn counts ranging from 3 to 114 per session (total content clearly present and readable) — none failed to parse, none came back empty.

This rules out corruption, truncation, or encoding issues in the source files. Whatever the Desktop UI is doing to decide what to render, it isn't using a "does this file contain valid messages" check — because they clearly do.

Hypothesis

The affected sessions were created by claude_code_version: 2.1.197, embedded in the Cowork backend at that time. The current Desktop build is 1.49585.0.0, presumably running a materially newer backend/parser. My best guess is a schema or transcript-format change between these versions that the current renderer doesn't handle backward-compatibly — e.g., a field that used to carry displayable content now expects a different shape, or a newer required field is absent from older records and the renderer silently drops the session's content instead of falling back gracefully.

One structural detail that may be relevant: some assistant entries in these older files have a leading thinking block with an empty thinking string before any text block appears in the same logical turn (split across multiple JSONL lines by uuid/parent_tool_use_id). If the renderer expects thinking and text to arrive differently structured in current-format sessions, an old-format empty-thinking-first pattern could plausibly cause it to bail on the whole turn.

Steps to Reproduce

1. Have Cowork/local-agent-mode session data on disk that was originally created by an older Claude Code CLI version (in my case, 2.1.197, sessions dated July–August 2026).
2. Open Claude Desktop 1.49585.0.0, navigate to the Cowork project associated with that session data.
3. Observe: the project and session title render correctly in the UI.
4. Open the session itself.
5. Observe: no message content is displayed, despite the underlying audit.jsonl containing valid, non-empty transcript data.

Ask

• Is this a known backward-compatibility gap in how the Desktop client parses older-format session transcripts?
• Is there an official/recommended migration path for old-format audit.jsonl files, or is silently dropping older content the intended behavior?
• Happy to provide full (redacted) audit.jsonl samples or the extraction script used to verify data integrity, if useful for reproducing this on your end.

What Should Happen?

New releases should persist all earlier Claude sessions

Error Messages/Logs

Steps to Reproduce

1. Have Cowork/local-agent-mode session data on disk that was originally created by an older Claude Code CLI version (in my case, 2.1.197, sessions dated July–August 2026).
2. Open Claude Desktop 1.49585.0.0, navigate to the Cowork project associated with that session data.
3. Observe: the project and session title render correctly in the UI.
4. Open the session itself.
5. Observe: no message content is displayed, despite the underlying audit.jsonl containing valid, non-empty transcript data.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.197

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_