Session/agent transcripts intermittently unresolvable ("not found in project directory") right after session start, breaking background-agent resume and permanently losing crashed-session transcripts

Title

Session/agent transcripts intermittently unresolvable ("not found in project directory") immediately at session start, breaking background-agent resume and permanently losing crashed-session transcripts

Environment

• Claude Code version: 2.1.198 (last auto-updated 2026-07-02, so not tied to a same-day update)
• OS: macOS (Darwin 25.5.0)
• Affects both a project on an iCloud Drive-synced path and an unrelated local git worktree — not specific to one project or filesystem type

Description

~/Library/Logs/Claude/main.log shows recurring entries of the form:

Failed to write rename to CLI transcript for local_<uuid>: Session <session-uuid> not found in project directory for <project-path>

This fires for a session's own ID, at or near session start, in a project whose session obviously exists (the log line is emitted from within that same session). It has occurred in two distinct forms with real functional impact, not just a cosmetic title-rename failure:

1. A session crashes mid-run, its transcript becomes permanently unrecoverable. A background sub-agent had produced ~125 items of in-progress work; when we tried to resume it after a suspected registry hiccup, it failed with No transcript found, and the session itself later couldn't be looked up at all via session-management tooling (Session <id> not found). All in-progress work in that agent's context was lost — nothing was ever persisted to disk, since the assumption going in was that the transcript itself was durable state.

1. The same failure recurs in a brand-new, freshly-restarted session, seconds after a background agent completes successfully. We spawned a background sub-agent, it finished cleanly and returned its result via the normal completion notification, and then attempting to resume that same agent (to hand it the next batch of work) failed immediately with No transcript found for agent ID: <id>. This ruled out "an update landed under a still-running session" as the explanation — there was no long-running session involved this time, it failed on a session that had just started.

We checked and ruled out, for the session in question: disk space (39GB free), iCloud sync/eviction state (fully caught up, nothing evicted, no .icloud placeholder files), and filesystem permissions (all normal, read/write both succeeded independently). The Failed to write rename to CLI transcript message appears only in today's log file, not in log files from two weeks or ten days prior, suggesting this is tied to the currently-installed build rather than being a long-standing intermittent issue we simply hadn't noticed.

Impact

• Background/async agents spawned via the Agent tool can become unresumable via their own agent ID almost immediately after completing, even though the harness's own completion notification reports them as finished successfully.
• If a session crashes (for any reason) while an agent is mid-task, that agent's entire in-progress context can become permanently unrecoverable — there is no way to extract partial results after the fact.
• This makes multi-step/multi-batch agent workflows unreliable unless the caller defensively persists all intermediate state to disk outside of any reliance on transcript durability — which works, but shouldn't be a requirement for basic resume to function.

Reproduction

Not reliably reproducible on command, but the following log grep confirms when/whether it's occurring:

grep "Failed to write rename to CLI transcript" ~/Library/Logs/Claude/main.log

Each hit includes the affected project path and the session UUID that couldn't be found. In our case it fired for two different project directories on the same day (an iCloud-synced Obsidian vault, and a local git worktree under .claude/worktrees/), both times attached to a session ID that had just been created.

What we'd like

• Confirmation of whether this is a known issue with the per-project session index / transcript resolution path.
• If it's a race between session creation and this rename-write (or a similar background write), whether that race could also affect Agent-tool SendMessage-based resume and crash-recovery transcript reads — since both use what appears to be the same underlying "look up session/agent by ID in this project's index" mechanism.