[FEATURE] Record the source session_ id in teleported session transcripts

Open 💬 0 comments Opened Jul 7, 2026 by RandyHaddad

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request

Problem Statement

When a session is materialized via claude --teleport <session-id>, the resulting local transcript is written under a fresh random UUID and does not contain the originating web session_... id anywhere in the JSONL. As a result, you cannot locate a teleported transcript by the id you used to fetch it — the only linkage is matching restored conversation content (channel/message ids, timestamps, prompt text) or picking the newest file in the project dir. That makes programmatic "fetch → locate → read" flows rely on brittle heuristics.

Proposed Solution

Record the source session_... id in the teleported transcript's metadata (e.g. a field on the session's header/first record), so a materialized trace is findable by the id used to fetch it.

Alternative Solutions

Currently: content-matching on restored conversation anchors, or newest-file-in-project-dir. Both are best-effort and version-fragile (the JSONL format itself is undocumented).

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

  1. A Slack-integration reply links a session_....
  2. Tooling teleports it headlessly.
  3. To open the right transcript, the tool must currently grep restored content because the session id isn't recorded.
  4. With this field, step 3 becomes a direct lookup by id.

Additional Context

Confirmed on 2.1.200: grep <session-id> against a freshly teleported transcript returns no match.

View original on GitHub ↗