[BUG] ENAMETOOLONG creating ~/.claude/projects/ when cwd is long (eCryptfs NAME_MAX=143); reproduces via Claude Desktop cowork bootstrap

Preflight Checklist

• [x] I have searched existing issues — see "Why this isn't a duplicate" below.
• [x] This is a single bug report.
• [x] Latest Claude Code version (2.1.143).

What's Wrong?

Claude Code creates a per-session dir at ~/.claude/projects/<sanitized-cwd>/. When the cwd is long enough, the sanitized name overflows the filesystem's NAME_MAX and mkdir fails with ENAMETOOLONG.

Prior reports exist (#10849, #19742, #54618), all closed NOT_PLANNED. Filing a fresh one because there are two new pieces of evidence I don't think the earlier reporters surfaced:

1. A filesystem class not represented in the prior reports caps NAME_MAX at 143, not 255. Ubuntu and Linux Mint shipped an "encrypted home" option for years that uses eCryptfs. On those installs getconf NAME_MAX $HOME returns 143, because eCryptfs has to fit the encrypted-filename overhead into the underlying 255-byte ext4 limit. The prior reports all worked under the 255-byte assumption. A 143-byte cap is a tighter constraint and a different class of affected user.

2. The long cwd in our reproducer is product-generated, not user-induced. Claude Desktop's cowork session-bootstrap spawns Claude Code with:

cwd = ~/.config/Claude/local-agent-mode-sessions/<accountId>/<orgId>/local_<uuid>/outputs

That sanitizes to a ~180-character entry under ~/.claude/projects/. Prior reports framed the bug as "user worked in a deep directory" — here the user didn't pick a deep directory; another Anthropic product picked it. So "use a shorter cwd" isn't a usable workaround in this reproducer.

The combination of (1) and (2) means a stock Ubuntu/Mint encrypted-home install opening a cowork session in Claude Desktop fails on the first mkdir. The user can't shorten the cwd and can't change NAME_MAX.

Downstream we had to ship a heavyweight workaround that costs the user a 2 GB LUKS-encrypted volume, a cryptsetup walkthrough, and a pam_mount config (aaddrick/claude-desktop-debian#614). That covers Claude Desktop users on Linux who're willing to follow a multi-step disk-encryption guide, which is a meaningful fraction of zero. The actual fix has to land on Claude Code's side — bounding a product-internal path-component length isn't a problem downstream can solve.

What Should Happen?

Bound the project-dir name to something that fits any plausible NAME_MAX. ≤140 chars leaves headroom for eCryptfs. Two options:

1. Truncate + hash suffix. Keep the first ~100 chars of the sanitized cwd, append -<first-8-of-sha256(full_cwd)>. Stays readable for short paths, deterministic, bounded.
2. Hash only. Drop the sanitized-cwd scheme and use a content hash. Simpler, but ls ~/.claude/projects/ becomes opaque.

Either works. The current self-describing scheme is nice-to-have but probably not load-bearing — happy to be corrected if there's something (CLI tab-completion, session lookup, migration scripts) that depends on the dir name being a literal sanitized path.

Migration is a non-issue if the new scheme is conditional. Apply the bounded scheme only when the sanitized name would exceed N chars (e.g., 140). Existing short directories keep their current name verbatim — no rename, no migration script. Existing long directories on affected filesystems don't exist by definition, because mkdir is what's currently failing.

Error Messages / Logs

Error: ENAMETOOLONG: name too long, mkdir '/home/user/.claude/projects/-config-Claude-local-agent-mode-sessions-<account>-<org>-local_<uuid>-outputs'
    at Module.mkdirSync (node:fs:1325:26)
    [...]

Sanitized. Full traces in aaddrick/claude-desktop-debian#590 and in the three prior upstream reports.

Steps to Reproduce

1. Ubuntu or Linux Mint install with the legacy "encrypted home" option (eCryptfs). Verify with df -T \$HOME (shows ecryptfs) and getconf NAME_MAX \$HOME (returns 143).
2. Install Claude Desktop on Linux (see aaddrick/claude-desktop-debian).
3. Launch Claude Desktop and start a cowork session.
4. Bootstrap fails. Claude Code's mkdir ~/.claude/projects/<sanitized-cowork-outputs-path>/ returns ENAMETOOLONG.

Reproduces every time on the affected configuration. Confirmed by @michelsfun in aaddrick/claude-desktop-debian#590.

Why this isn't a duplicate

Prior reports framed it as "user worked in a deep directory." The new datapoints:

• The affected filesystem caps at 143, not the 255 those reports referenced.
• The long cwd in our reproducer is generated by Claude Desktop's cowork flow, not by the user.

Worth another look on those grounds.

Related

• aaddrick/claude-desktop-debian#590 — original Linux report from @michelsfun
• aaddrick/claude-desktop-debian#614 — downstream LUKS-volume workaround we had to ship (merged)
• aaddrick/claude-desktop-debian#619 — follow-up runtime detector
• anthropics/claude-code#10849, #19742, #54618 — prior closures, all NOT_PLANNED

Suggested labels

bug, has repro, area:cowork, area:desktop, area:packaging.

/cc @felixrieseberg — flagging since you noted in anthropics/claude-code#22543 that you work on Cowork and Claude Code, and this sits at the seam between them.

Note from human @aaddrick here: Linux isn't a platform Anthropic officially supports for Claude Desktop. What I run downstream is community-side repackaging, and the users hitting this aren't on a platform you've made commitments around. That said, they're real users and this has cropped up on a couple different repos and reddit. Best case angle on this is future proofing against bug reports if you ever push a Linux client. Appreciate you and any look you can give it.

---
Written by Claude Opus 4.7 via Claude Code (except that last bit...)