[BUG] Windows MSIX: output files in local-agent-mode-sessions exceed MAX_PATH (260 chars) — Office apps cannot open generated files

[BUG] Windows MSIX: output files in local-agent-mode-sessions exceed MAX_PATH (260 chars) — Office apps cannot open generated files

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?

On Windows, Claude Desktop (MSIX package) stores Cowork/agent output files at a path that consumes 238 characters before the filename even starts. Since Microsoft Office apps (Word, PowerPoint, Excel) do not honor the LongPathsEnabled registry key and enforce the legacy 260-character MAX_PATH limit, any generated file with a name longer than ~22 characters cannot be opened by double-clicking from Explorer.

This affects every Windows user on the MSIX build who uses Cowork/agent mode to generate Office-compatible files.

Path breakdown (measured on a fresh install, 8-char Windows username):

C:\Users\<8chars>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\<36-char-GUID>\<36-char-GUID>\local_<36-char-GUID>\outputs\

| Segment | Characters |
|---------|-----------|
| C:\Users\<8chars>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ | 93 |
| local-agent-mode-sessions\ | 27 |
| <session-GUID>\ | 37 |
| <account-GUID>\ | 37 |
| local_<space-GUID>\ | 43 |
| outputs\ | 8 |
| Total (before filename) | 238 |

Remaining characters for a filename before hitting 260: 22 characters (including the backslash).

Any filename longer than 21 characters will fail. Common Claude-generated filenames easily exceed this: quarterly-report.pptx (21), meeting-notes-july.docx (23), project-timeline-v2.xlsx (24).

Why LongPathsEnabled doesn't help:

The registry key (HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1) only removes the OS-level gate. Each application must also declare longPathAware in its own manifest. Microsoft Office apps (as of July 2026) do not have this manifest entry. File Explorer can browse the path fine, but double-clicking a file hands it to the associated app, which rejects the path.

What Should Happen?

Output files should be stored at a path short enough that any Windows application — including those without long-path-aware manifests — can open them. A path of ~180 characters to the outputs folder would leave ~80 characters for filenames, which is more than sufficient.

Suggested approaches:

1. Store outputs in a shorter location (e.g., %LOCALAPPDATA%\Claude\outputs\<session-id>\)
2. Use abbreviated identifiers instead of three nested full-length GUIDs
3. Copy the file to a temp location before passing to shell.openPath() or the associated application

Error Messages/Logs

When clicking a generated .pptx file from Explorer in the outputs folder:

PowerPoint: "The path is too long. Shorten the file name or folder names, or try a different folder."

No error in Claude Desktop itself. "Show in Folder" works correctly (Explorer honors long paths). The failure is in the handoff to the associated application.

Steps to Reproduce

1. Install Claude Desktop on Windows via the official installer (MSIX package Claude_pzs8sxrjxfjjc)
2. Sign in, open Cowork/agent mode
3. Ask Claude to generate a file with a typical name (e.g., "Create a PowerPoint presentation called 'Project Status Update July 2026'")
4. When the file appears, click the dropdown arrow → "Show in Folder"
5. Explorer opens to the outputs directory — the file is visible
6. Double-click the .pptx file
7. PowerPoint shows "path too long" error
8. Copy the same file to Desktop → double-click → opens fine

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — reported to have worked prior to a Claude Desktop update that introduced the third level of GUID nesting (local_<GUID>) in the session path. The additional 43 characters pushed many filenames over the 260 limit.

Claude Code Version

N/A — this is a Claude Desktop / Cowork issue, not Claude Code CLI. Filing here as there is no dedicated Claude Desktop issue tracker.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Environment

• Windows 11 24H2 (Build 26100)
• MSIX package: Claude_pzs8sxrjxfjjc
• LongPathsEnabled registry value: 1 (confirmed — does not resolve the issue)
• No relevant GPOs affecting filesystem paths
• Affects enterprise-managed machines (Esri domain-joined workstations)

Related closed issues (all auto-closed as stale, none resolved)

• #52980 — "Open in Word" and "Show in Folder" completely broken in Cowork
• #49953 — Dispatch "output" button fails with "Location is not available"
• #58421 — System prompt cites non-existent AppData\Roaming\Claude paths
• #61443 — File Pane fails "outside the session folder" on existing files

Measured path lengths from a fresh install:

238 chars — outputs folder
238 chars — uploads folder
251 chars — .claude/.claude.json
280 chars — .claude/backups/.claude.json.backup.<timestamp>
439 chars — .claude/projects/<flattened-path-as-foldername>

The .claude/projects/ entry at 439 characters is particularly egregious — it flattens the full virtualized path into a folder name, creating paths that far exceed even the 32,767-character extended-length limit that some APIs support.

Workaround for affected users

Move or copy the generated file to Desktop (or any short path) before opening. This is the only reliable workaround while Office apps lack long-path-aware manifests.