[BUG] Windows desktop: cowork session paths reach 472 chars (212 over MAX_PATH); 117 files already past the limit. Windows sibling of #80753

Preflight Checklist

• [x] I have searched existing issues. The closest match is #80753 — same root cause on a different platform, against a different limit, with a different observed symptom. The distinction is set out under "Relation to #80753" below.
• [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?

Summary

On Windows, the desktop app builds session working directories deep enough that Claude Code's
project-key encoding pushes stored paths well past MAX_PATH (260). On this machine 117 files
across three trees are already over the limit, the worst at 472 characters — 212 over.

Nothing has broken yet, and I want to be upfront about that: this is a latent report, not an outage.
It is worth filing anyway because the identical root cause is already causing total silent data
loss on Linux in #80753, and because the fix is a code path that already exists and is simply
never exercised.

Root cause

Claude Code stores transcripts at <configHome>/projects/<projectKey>/..., where projectKey is the
entire working-directory path with every non-alphanumeric character replaced by a hyphen. From the
shipped binary (v2.1.259):

var DL = 200;
function k(e)  { return e.replace(/[^a-zA-Z0-9]/g, "-") }
function we(e) { return Math.abs(S4(e)).toString(36) }        // 32-bit hash
function rk(e) { let n = k(e); if (n.length <= DL) return n; return n.slice(0,DL) + "-" + we(e) }
function wm(e) { return Dgr() ?? rk(e) }                       // Dgr() = CLAUDE_CODE_PROJECT_DIR_NAME
function n7e(e){ return jf(Qd(), rk(e)) + ei }                 // temp/scratchpad root — no override hook

Two desktop-app path shapes make this expensive on Windows:

1. No-folder sessions get a scratch workspace at

%APPDATA%\Claude\scratch-workspaces\<uuid>\<uuid>\scratch-<date>-<hash> — 156 characters
containing two UUIDs. That whole string becomes one directory name, reproducing both UUIDs, and a
third UUID (the session id) is appended as the next segment.

1. Cowork / local-agent-mode sessions are worse. They live at

%APPDATA%\Claude\local-agent-mode-sessions\<acct>\<org>\local_<uuid>\ and are given their *own
nested* .claude config dir. The encoded slug of that long path is then written inside the
path it encodes, so the length is counted twice in one path.

That second shape is exactly the layout described in #80753.

Measurements (2026-09-03, Windows 11 Pro 10.0.26200, LongPathsEnabled=1)

| Tree | Files | Over 260 | Longest |
| --- | ---: | ---: | ---: |
| %APPDATA%\Claude\local-agent-mode-sessions | 879 | 4 | 472 |
| %USERPROFILE%\.claude\projects | 2,440 | 66 | 295 |
| %LOCALAPPDATA%\Temp\claude | 28,418 | 47 | 291 |

The 472-char path, username redacted:

C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\28a3d35c-…\543a0bdd-…\local_9025c258-…\.claude\projects\C--Users-<user>-AppData-Roaming-Claude-local-agent-mode-sessions-28a3d35c-…-543a0bdd-…-local-9025c258-…-outputs\d2d7af4f-…\tool-results\toolu_01DhBZ53LWX5rgN2Wt3eVTNR.json

Character budget for the no-folder case (295 chars):

| Component | Chars | Running |
| --- | ---: | ---: |
| C:\Users\<user>\.claude | 22 | 22 |
| \projects | 9 | 31 |
| \ + encoded project key | 157 | 188 |
| \ + session UUID | 37 | 225 |
| \subagents | 10 | 235 |
| \workflows | 10 | 245 |
| \wf_<id> | 16 | 261 |
| \agent-<id>.meta.json | 34 | 295 |

By contrast a named project folder such as C:\Projects\JobHunt yields a 19-char key and a 171-char
deepest path. The problem is specific to app-generated working directories.

The scratchpad base is the tightest spot

The scratchpad is %LOCALAPPDATA%\Temp\claude\<key>\<session-uuid>\scratchpad, whose length is
89 + key length before any file is written into it:

| Project key length | Scratchpad base | Room for a filename under 260 |
| --- | ---: | ---: |
| 19 (named project) | 108 | 151 |
| 156 (no-folder session) | 245 | 14 |
| 207 (the capped maximum) | 296 | −37 — over before any file exists |

In a no-folder session, any scratchpad file whose name exceeds 14 characters is already past
MAX_PATH. That is effectively every file, and these are user-facing deliverables.

Bounds

The key is hard-capped at 207 chars — verified empirically, not just read from source: launching from
a 225-char working directory produced a key of exactly 200 truncated characters + - + a 6-char
base36 hash. Subagent nesting does not recurse (agentTranscriptSubdirs is a flat map), measured at
1,423 files at depth 2 and none deeper. So worst case is bounded at ~346 for the transcript tree —
but the cowork tree at 472 already exceeds that, because its input path is itself long.

What actually breaks today

I tested a 301-char path against the local toolchain. Almost everything coped, because Windows 11
build 26100 ships long-path-aware in-box tools and LongPathsEnabled=1:

Passed: Python 3.14, PowerShell 5.1 cmdlets, System.IO, cmd.exe (dir/type/copy/cd),
Copy-Item -Recurse, robocopy, Compress-Archive, Expand-Archive, tar.exe,
Shell.Application.CopyHere (the Explorer engine, wrote a 310-char destination).

Failed: git for Windows 2.43.0 without core.longpaths. This one is the dangerous kind — it does
not error, it skips:

| core.longpaths | git add -A exit | Files staged |
| --- | ---: | ---: |
| false | 0 | 0 |
| true | 0 | 1 |

git status then reports a clean tree. Any git-based backup of ~/.claude silently omits these
files and reports success. Note this failure occurred with LongPathsEnabled=1 active — git uses
its own MAX_PATH-sized buffers and never consults the registry key, so the two settings are
independent.

Relation to #80753

#80753 (open, bug/area:desktop, filed 2026-07-24, no comments) reports the same encoding against
a different limit: on eCryptfs homes NAME_MAX=143, the ~179-char single component fails
ENAMETOOLONG, the error is swallowed, and every follow-up dies with "No conversation found". Same
cause, same desktop-generated local-agent-mode-sessions/.../outputs path shape, different
filesystem ceiling. A fix that shortens the stored key resolves both. Filing separately since the
platform, the limit, and the observed symptom differ.

What Should Happen?

Stored paths should stay comfortably under the platform limit regardless of how long the working
directory the host hands to Claude Code is.

Suggested fixes, in order of preference:

1. **Have the desktop app pass CLAUDE_CODE_PROJECT_DIR_NAME (with CLAUDE_CONFIG_DIR) for

app-generated workspaces.** The mechanism already exists, shipped in v2.1.234, and is documented
for precisely this case — "a host that embeds Claude Code and gives each session its own config
directory". Nothing currently uses it. This alone takes the 156-char key to something short.

1. Extend the same override to the temp/scratchpad root. n7e() calls rk() directly with no

override hook, so fix 1 leaves the 245-char scratchpad base untouched.

1. Lower the 200-char cap on win32, or hash more aggressively there. 200 + hash = 207 is already

80% of MAX_PATH for a single path segment.

1. Don't nest a session's .claude inside the path it encodes. The cowork layout counts the same

long string twice; that is where the 472 comes from.

1. Shorten the generated workspace paths themselves. Two full UUIDs plus a date plus a hash is

more entropy than one disposable workspace needs.

Error Messages/Logs

# git for Windows 2.43.0, core.longpaths unset, LongPathsEnabled=1, 302-char file
$ git add -A
warning: could not open directory 'C--Users-<user>-AppData-Roaming-Claude-scratch-workspaces-.../subagents/workflows/wf_8a161266-334/': Filename too long
$ echo $?
0
$ git diff --cached --name-only | wc -l
0
$ git status --porcelain
# (empty — reports clean)

No error is surfaced anywhere by Claude Code itself; the paths are simply written and read back
successfully by the Bun runtime, which is long-path aware.

Environment

• Windows 11 Pro 10.0.26200 (build 26100)
• Claude Code CLI 2.1.259 (~/.local/bin/claude.exe); desktop bundle 2.1.258
• HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled = 1, no policy override
• git 2.43.0.windows.1, Python 3.14.0, PowerShell 5.1.26100.9168