teleport: web→local handoff drops prompt history, and memory resolves to a different project key than transcripts

Continuing a Claude Code web session on a local Mac surfaces three gaps in session portability: one missing handoff path, and two inconsistencies in what --teleport carries over.

Environment: Claude Code 2.1.263 (native install), macOS 26.6.2, web/cloud session teleported to the local CLI with claude --teleport.

Paths below are anonymized: <user> is my macOS username and <proj> / <proj>_b are two sibling clones of the same private repo.

---

1. Feature request — a web session cannot be opened in the Claude desktop app

Handoff is currently asymmetric:

| direction | supported |
|---|---|
| web → terminal CLI | yes (claude --teleport) |
| desktop app → web | yes ("Continue in → Claude Code on the Web") |
| terminal CLI → web | yes (claude --cloud) |
| web → desktop app | no |

The desktop app's "Continue in" menu only pushes a local session out to the web; there is no inverse. For anyone whose primary local surface is the desktop app rather than a terminal, a web session can only be continued by dropping to the CLI. --teleport is documented as CLI-only, so this reads as a genuinely missing edge rather than a discoverability problem.

2. Bug — --teleport restores conversation context but not prompt history

Teleport correctly restores the conversation (the transcript is written to ~/.claude/projects/<cwd-key>/<session-id>.jsonl), but the up-arrow prompt buffer is empty in the resumed session.

~/.claude/history.jsonl entries carry a project field set to the local cwd. Prompts issued during the web session are never written there, so nothing from the cloud session is recoverable in the local history buffer. The session "moved", but a user-visible part of its state did not come with it.

Expected: prompts from the teleported session appear in the local history buffer, keyed to the directory teleport resumed into.

3. Bug — memory and history/transcripts resolve to different project keys in the same session

In a single session with cwd /Users/<user>/Documents/projects/<proj>_b, three subsystems disagreed about which project this is:

• transcript → ~/.claude/projects/-Users-<user>-Documents-projects-<proj>-b/ ✅ (has the -b)
• history.jsonl entries → project: /Users/<user>/Documents/projects/<proj>_b ✅ (has the _b)
• memory → ~/.claude/projects/-Users-<user>-Documents-projects-<proj>/memory/ ❌ (no -b)

$ ls ~/.claude/projects/-Users-<user>-Documents-projects-<proj>/memory/ | head -3
MEMORY.md
<redacted>.md
<redacted>.md

$ ls ~/.claude/projects/-Users-<user>-Documents-projects-<proj>-b/memory/
ls: .../-Users-<user>-Documents-projects-<proj>-b/memory/: No such file or directory

So within one session, memory resolved to the sibling directory's key while history and transcripts resolved to the actual cwd's key. Whichever is correct, the two should agree — otherwise "does my state carry over?" has a different answer depending on which piece of state you ask about.

To be clear about what is not being reported: two sibling clones of one repo naturally get separate per-directory history, and that part reads as by design. The inconsistency in item 3 is between two subsystems resolving the same cwd differently.

---

Why these compound

Individually each is small. Together they mean a web→local handoff silently drops user-visible state, with no indication at resume time about what came along and what did not.