Problem
echos open installs a Claude transcript under the project directory it chose (default: cwd, or --dir), then prints claude --resume <id> with no directory context. But claude --resume is path-bound: Claude Code looks for the session under ~/.claude/projects/<encoded-current-dir>/. If the recipient runs the printed command from a different directory than the one open installed into, Claude reports No conversation found with session ID: <id> even though the file is present.
This is not the send-side path bug (#3) nor the encoder gap (#5) — encoding here is correct; the transcript is installed and decrypts/verifies fine. The failure is purely that the resume hint doesn't tell the user where to run it.
Real-world repro
A recipient opened a shared session, then ran claude --resume <id> from ~/work/heurema (the parent), while open had installed it under the ~/work/heurema/echos project dir. Claude looked under -Users-<user>-work-heurema/, the file was under -Users-<user>-work-heurema-echos/, so resume failed. It cost a full debugging session to trace back to "run it from the project directory."
Suggested fix
open already knows the installed project directory (the parent of installed_path). Make the resume hint self-sufficient:
- Text mode: print
cd <project-dir> && claude --resume <id> (or clearly state "resume from <project-dir>") instead of a bare claude --resume <id>.
- Optionally warn when the install directory differs from the current working directory, so the mismatch is surfaced at
open time rather than at a confusing resume failure later.
--json: consider adding a project_dir field alongside resume_command so agents can cd correctly.- Codex's
codex resume <id> is not path-bound the same way, so this is Claude-specific — keep the hint tool-aware.
Why it matters
The path-bound-resume constraint is inherent to Claude Code, but the current context-free hint makes it bite every recipient who isn't already standing in the exact install directory. Surfacing the directory turns a silent, hard-to-diagnose failure into a copy-pasteable command.
Problem
echos openinstalls a Claude transcript under the project directory it chose (default: cwd, or--dir), then printsclaude --resume <id>with no directory context. Butclaude --resumeis path-bound: Claude Code looks for the session under~/.claude/projects/<encoded-current-dir>/. If the recipient runs the printed command from a different directory than the oneopeninstalled into, Claude reportsNo conversation found with session ID: <id>even though the file is present.This is not the send-side path bug (#3) nor the encoder gap (#5) — encoding here is correct; the transcript is installed and decrypts/verifies fine. The failure is purely that the resume hint doesn't tell the user where to run it.
Real-world repro
A recipient opened a shared session, then ran
claude --resume <id>from~/work/heurema(the parent), whileopenhad installed it under the~/work/heurema/echosproject dir. Claude looked under-Users-<user>-work-heurema/, the file was under-Users-<user>-work-heurema-echos/, so resume failed. It cost a full debugging session to trace back to "run it from the project directory."Suggested fix
openalready knows the installed project directory (the parent ofinstalled_path). Make the resume hint self-sufficient:cd <project-dir> && claude --resume <id>(or clearly state "resume from<project-dir>") instead of a bareclaude --resume <id>.opentime rather than at a confusing resume failure later.--json: consider adding aproject_dirfield alongsideresume_commandso agents cancdcorrectly.codex resume <id>is not path-bound the same way, so this is Claude-specific — keep the hint tool-aware.Why it matters
The path-bound-resume constraint is inherent to Claude Code, but the current context-free hint makes it bite every recipient who isn't already standing in the exact install directory. Surfacing the directory turns a silent, hard-to-diagnose failure into a copy-pasteable command.