[BUG] Windows: session export fails on transcript paths longer than 260 characters

Summary

On Windows, exporting a Cowork session fails with "Transcript couldn't be read. You can try again." Retrying never works. The transcript file is present and intact; the export code cannot open it because its path is longer than the Win32 260-character limit and the native file reader does not use extended-length paths.

The same bug silently omitted the transcript from export archives from 2026-07-01. Version 1.21459.0 (2026-07-14) then added a check for the missing transcript, so that "the export shows a clear error when it can't be included" per the changelog. That check turned a silent omission into the visible error.

Environment

• Claude Desktop 1.24012.9.0 (MSIX), Windows 11 Pro 26200, x64
• Sessions are local agent mode (Cowork), not attached to a project folder

What happens

Transcript path for a Cowork session:

C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\<deviceId>\<orgId>\local_<sessionId>\.claude\projects\<encoded-cwd>\<cliSessionId>.jsonl

That is 435 characters on this machine. The length is structural, not a local quirk. Writing R for the length of the sessions root:

• session dir = R + 117 (two 36-char UUIDs plus local_ + a third)
• cwd = session dir + \outputs = R + 125
• encoded cwd (separators replaced with dashes) is the same length again
• transcript path = 2R + 303

With R = 66 the result is 435, matching the observed path. Because the constant alone is 303, no configuration can bring this under 260, including a shorter user-data directory. VM-mode sessions (/sessions/<name> as cwd) land at 273 to 289 characters, also over the limit.

In exportSessionTranscript, the file is found with fs.promises.lstat, which libuv converts to an extended-length path, so the size is read correctly. It is then read through readRegularFileNoFollow, which goes to SafeRoot.open and the native openRootDir. That native call uses the raw path, so it fails on anything past 260 characters. The failure is caught and returned as null, the transcript is skipped, and the export reports "Transcript couldn't be read."

claude.exe has no longPathAware element in its manifest (dpiAware and requestedExecutionLevel are present), so the machine-wide LongPathsEnabled registry setting does not help either.

Timeline

Export archives on disk, checked for a .jsonl entry:

• 44 archives from 2026-04-21 through 2026-06-30: transcript present in every one
• 14 archives from 2026-07-01 through 2026-07-09: no transcript in any of them

The last archive with a transcript is dated 2026-06-30. The first archive without one is dated 2026-07-01. The releases on those two dates are 1.17377.1 and 1.17377.2. I cannot confirm the running version from logs for those days, because the oldest log kept on this machine starts 2026-07-06.

Log evidence for the visible error, from %APPDATA%\Claude\logs:

• 2026-07-09 13:45, app 1.19367.0: [transcriptExport] Session ... exported to ...session-export-1783619145011.zip (5113419 bytes, 38 files) (that archive has no transcript inside)
• 2026-07-17 11:01, app 1.22209.0: [transcriptExport] Transcript present but unreadable — skipping, then No transcript found — failing export, with transcriptUnreadable: true and transcriptTooLarge: false

1.21459.0 (2026-07-14) is the release that added the missing-transcript check.

Reproduction

1. On Windows, open a Cowork session with no project folder attached.
2. Run /export.
3. The export fails with "Transcript couldn't be read. You can try again."

The transcript itself reads fine with any long-path-aware call, for example [System.IO.File]::Copy("\\?\" + $path, $dest) in PowerShell, or Node's fs.readFile on the same path.

Suggested fix

Prefix paths with \\?\ in the native root-open path (after canonicalization, since the prefix disables normalization), or add <longPathAware>true</longPathAware> to the executable manifest so the machine-wide setting applies. The first works regardless of the user's registry setting.

Shortening the stored path would also help, but on its own it does not fix VM-mode sessions at 273 to 289 characters.