[BUG] Linux desktop: chats silently lose transcripts on eCryptfs homes — project dir exceeds NAME_MAX=143 (ENAMETOOLONG), every follow-up fails with "No conversation found" (re: #59726)

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?

Summary

On the official Claude Desktop for Linux (installed from Anthropic's apt repo at downloads.claude.ai, v1.24012.0, engine/CCD 2.1.215), every local-agent chat on a system with an eCryptfs-encrypted home directory (the standard "encrypt my home folder" option on Ubuntu/Linux Mint) silently fails to persist its transcript. The first message appears to work; every subsequent message fails with:

No conversation found with session ID: <uuid>

This is #59726, which was closed as "not planned" by the stale bot without a fix — the bot said to open a new issue if still relevant. It is now MORE relevant: that report predated the official Linux client and was framed around community repackaging ("not an officially supported platform"). The official client now ships with this defect, and the failure mode is worse than the original report described: it is not just cowork bootstrap mkdir — it is silent, total conversation loss in the normal chat flow.

Root cause (verified with strace on a live desktop session)

The engine stores transcripts at CLAUDE_CONFIG_DIR/projects/<sanitized-cwd>/<session-id>.jsonl. Desktop local-agent sessions use

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

which sanitizes to a single ~179-char directory component. eCryptfs caps NAME_MAX at 143 (encrypted-filename overhead within ext4's 255). Result, captured with strace -f -e trace=%file on the engine during a real turn:

mkdir(".../.claude/projects/-home-<user>--config-Claude-local-agent-mode-sessions-<acct>-<org>-local-<uuid>-outputs", 0700) = -1 ENAMETOOLONG (File name too long)
openat(AT_FDCWD, ".../<session-id>.jsonl", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = -1 ENAMETOOLONG (File name too long)

The error is swallowed. The turn is reported healthy (had_first_response: true, transcript_size_bytes: undefined) and the app then spawns --resume=<id>, which fails with "No conversation found with session ID". Nothing in any user-visible surface or log points at the filesystem error; root-causing this took a full day of eliminating misleading suspects (MCP connectors, app version, engine version, cowork VM path — all coincidental).

Reproduction

1. Ubuntu/Mint install with the "encrypted home" (eCryptfs) option. getconf NAME_MAX $HOME → 143.
2. Install the official claude-desktop deb from Anthropic's apt repo; sign in; start a local session chat in any trusted folder.
3. Send a message; after the reply, send a follow-up → "No conversation found with session ID". 100% reproducible.

Impact

• Total, silent conversation loss for every desktop chat on affected systems. ~/.claude/projects equivalents stay empty; nothing is ever written.
• Affects exactly the users who opted into disk encryption.
• The official Linux beta means this is no longer a community-repackaging concern.

Fix suggestion (same as #59726)

Bound the sanitized project-dir name (truncate + short hash suffix when >140 chars, or probe pathconf(PC_NAME_MAX)), and surface transcript-write failures instead of reporting a healthy turn. Conditional bounding needs no migration: long dirs never existed because mkdir always failed.

Lightweight workaround (verified, no LUKS volume needed)

Symlink the org-level session dir to a short path inside the encrypted home:

~/.config/Claude/local-agent-mode-sessions/<acct>/<org> -> ~/.cs

Sanitized cwd drops to ~68 chars; saves and resumes then work (verified end-to-end, transcripts written and resumable). Much lighter than the 2 GB LUKS workaround shipped downstream in aaddrick/claude-desktop-debian#614.

References

• #59726 (closed as stale, not fixed) and its priors #10849, #19742, #54618 (all closed NOT_PLANNED)
• The resume-path statx variant reported by @rheidt in #59726 matches our trace exactly
• Also reported today through the desktop app's Help → Report an issue

Environment: Linux Mint (Ubuntu 24.04 base), kernel 7.0.0-28-generic, eCryptfs home; claude-desktop 1.24012.0 (also reproduced on 1.22209.3); engine/CCD 2.1.215 (also reproduced with engine 2.1.205); reproduced with the cowork VM path both enabled and disabled.

What Should Happen?

Conversations should be saved and resumable regardless of the filesystem's NAME_MAX: the project directory name should be bounded (truncate + hash when over ~140 chars, or probe PC_NAME_MAX). If a transcript write fails, the failure should be surfaced to the user/logs instead of the turn being reported successful and the conversation silently lost.

Error Messages/Logs

User-visible error on every follow-up message (and on retry of any errored chat):

No conversation found with session ID: 4e88c517-8269-4056-a094-0db15b39a388

Desktop main.log around one failing turn (session local_e3baf29c, engine spawn without --resume, then respawn with --resume):

2026-07-23 20:36:09 [info] [CycleHealth] Healthy cycle: { cli_session_id: '42a3af7e-...', had_first_response: true, seconds_to_outcome: 7, is_resume: false, transcript_size_bytes: undefined }
2026-07-23 20:36:13 [warn] [HostLoop] cli.js stderr: No conversation found with session ID: 42a3af7e-...
2026-07-23 20:36:13 [info] [Result] Turn failed for session local_e3baf29c-...: subtype=error_during_execution, is_error=true, unhealthy_reason: 'api_error', error_category: 'session_not_found'

strace (-f -e trace=%file) of the engine during the first (non-resume) turn — the write that silently fails:

mkdir("/home/sandman/.config/Claude/local-agent-mode-sessions/<acct-uuid>/<org-uuid>/local_<uuid>/.claude/projects/-home-sandman--config-Claude-local-agent-mode-sessions-<acct-uuid>-<org-uuid>-local-<uuid>-outputs", 0700) = -1 ENAMETOOLONG (File name too long)
openat(AT_FDCWD, ".../projects/-home-sandman--config-...-outputs/4e88c517-8269-4056-a094-0db15b39a388.jsonl", O_WRONLY|O_CREAT|O_APPEND|O_LARGEFILE, 0600) = -1 ENAMETOOLONG (File name too long)
statx(AT_FDCWD, ".../4e88c517-8269-4056-a094-0db15b39a388.jsonl", ...) = -1 ENAMETOOLONG (File name too long)

Filesystem confirmation:

$ getconf NAME_MAX $HOME
143
$ mkdir ~/$(printf 'x%.0s' {1..179})
mkdir: cannot create directory: File name too long
$ mount | grep ecryptfs
/home/.ecryptfs/sandman/.Private on /home/sandman type ecryptfs (...)

Steps to Reproduce

1. Install Ubuntu or Linux Mint with the "encrypt my home folder" option (eCryptfs). Verify: getconf NAME_MAX $HOME returns 143 (not 255).
2. Install the official Claude Desktop for Linux from Anthropic's apt repository (downloads.claude.ai/claude-desktop/apt/stable), v1.24012.0.
3. Sign in, trust any folder, and start a local session (chat with folder access).
4. Send any message. The reply streams normally (the turn runs in-memory), but no transcript is written — <session-dir>/.claude/projects/ stays empty because the sanitized cwd (~179 chars) exceeds NAME_MAX=143.
5. Send a follow-up message (or let the app's idle timeout kill the engine process and retry). The app spawns the engine with --resume=<session-id> → "No conversation found with session ID: <uuid>". 100% reproducible.

Note: the long cwd is generated by Claude Desktop itself (~/.config/Claude/local-agent-mode-sessions/<accountId>/<orgId>/local_<uuid>/outputs) — the user cannot choose a shorter path. Minimal repro of the underlying limit: mkdir ~/$(printf 'x%.0s' {1..179}) fails with "File name too long" on eCryptfs while succeeding on plain ext4.

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

None — transcript persistence has never worked on eCryptfs homes (multi-turn only appeared to work in older desktop builds because the engine process stayed alive between turns)

Claude Code Version

2.1.215 (Claude Code) — CCD engine bundled/downloaded by Claude Desktop 1.24012.0; also reproduced with 2.1.205

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Context that took a day to untangle: the visible error (session_not_found) points away from the real cause, and several plausible-looking suspects (a newly added MCP connector, an app auto-update on the same day, the cowork VM path, engine version) were all coincidental. The silent swallow is the expensive part — surfacing the ENAMETOOLONG would have made this a five-minute diagnosis.

Verified lightweight workaround (no LUKS needed, keeps data encrypted): symlink the org-level session dir to a short path inside the encrypted home — ~/.config/Claude/local-agent-mode-sessions/<acct>/<org> → ~/.cs — sanitized cwd drops to ~68 chars; transcripts write and --resume works.

Same report also filed today via the desktop app's Help → Report an issue. Prior reports of this class: #59726 (closed stale, has the same fix proposal), #10849, #19742, #54618 (all closed NOT_PLANNED under the "Linux isn't officially supported" rationale, which the official Linux desktop client has now overtaken).