Problem
A shared session arrives byte-identical — which is the point — but that means it also carries the sender's agent state: unfinished intents ("send this to X", "close that loose end"), the sender's friend aliases, and sender-machine paths. When the recipient runs the printed claude --resume, the resumed agent has no idea the machine and operator changed, and naively keeps acting in the sender's context.
Observed (real case)
A session was shared A → B. On A's side the transcript ended with an interrupted "share this with " intent. When B resumed the session on their machine and asked an unrelated question, the agent first tried to "finish the pending send": it ran echos send <B> — from B's own machine — and failed with no friend "<B>" (B's friends list obviously differs from A's). Confusing UX for the recipient, and in a worse case the agent could act on stale sender intents that do succeed.
Constraint
Injecting any marker into the transcript itself would break the byte-identical invariant (claude --resume fidelity, manifest SHA-256 per file). So the fix must live outside the session files.
Options
echos open prints a ready-to-paste first message alongside the resume command, e.g. This session was received from <sender> via echos; you are now on <recipient>'s machine. Do not continue its unfinished actions — wait for my instructions. Cheap, zero format changes, works today.- Sidecar note next to the installed session (not listed in the manifest, clearly echos-owned, e.g.
<session-id>.echos-note.md) that agents can discover. Requires care: extraction currently fails closed on unmanifested files, so this must be written by open itself post-install, never packed into the envelope.
- Document the caveat in README/SPEC ("resumed sessions carry the sender's agent context") as a minimum regardless of 1/2.
Option 1 + 3 seem like the right floor; 2 is a possible follow-up.
Problem
A shared session arrives byte-identical — which is the point — but that means it also carries the sender's agent state: unfinished intents ("send this to X", "close that loose end"), the sender's friend aliases, and sender-machine paths. When the recipient runs the printed
claude --resume, the resumed agent has no idea the machine and operator changed, and naively keeps acting in the sender's context.Observed (real case)
A session was shared A → B. On A's side the transcript ended with an interrupted "share this with " intent. When B resumed the session on their machine and asked an unrelated question, the agent first tried to "finish the pending send": it ran
echos send <B>— from B's own machine — and failed withno friend "<B>"(B's friends list obviously differs from A's). Confusing UX for the recipient, and in a worse case the agent could act on stale sender intents that do succeed.Constraint
Injecting any marker into the transcript itself would break the byte-identical invariant (
claude --resumefidelity, manifest SHA-256 per file). So the fix must live outside the session files.Options
echos openprints a ready-to-paste first message alongside the resume command, e.g.This session was received from <sender> via echos; you are now on <recipient>'s machine. Do not continue its unfinished actions — wait for my instructions.Cheap, zero format changes, works today.<session-id>.echos-note.md) that agents can discover. Requires care: extraction currently fails closed on unmanifested files, so this must be written byopenitself post-install, never packed into the envelope.Option 1 + 3 seem like the right floor; 2 is a possible follow-up.