[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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:

```json
{"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:

```json
{"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_/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

```shell

```

### 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_

Start by reviewing the affected audit.jsonl transcript structure and run the reported PowerShell extraction across the 16 affected sessions. Compare older CLI 2.1.197 records with current-format sessions, focusing on the empty thinking blocks and split turns described in the report. Done means historical message content renders in Claude Desktop without losing valid transcript data.

索引モデルが issue の本文から書いたものです。