hcom list --json session_id can diverge from a session's live session id (after /resume or fork)

[zane668]

Summary

For the same running instance, the session_id reported by hcom list --json can differ from that session's live session id (the id the underlying agent's session actually has right now). They appear to live in two different id spaces, and I'd like to understand whether that's by design before assuming it's a bug.

What I see

• hcom list --json <name> (querying a peer, not self) reports the session_id that was captured when the instance registered/launched.
• After the underlying agent's session id changes during the instance's life — e.g. a Claude /resume, or a fork that starts a new session file — that stored value is not updated, so the instance keeps reporting its original launch-time id.
• Meanwhile the session is now actually running under a different, newer session id.

Looking at src/commands/list.rs, the JSON session_id for a looked-up instance comes from the stored data.session_id; only the self-query path overrides it with the caller's live identity (sender_identity.session_id). So a peer lookup always returns the registration-time value.

Reproduction

1. Launch a session through hcom and note its session_id via hcom list --json <name>.
2. Change the underlying agent's session id mid-life — e.g. /resume the Claude session, or fork it, so a new session file / id is in effect.
3. hcom list --json <name> still reports the original launch-time session_id, not the id the session is currently running under.

(Most reliably observed on relay / resume / fork-style sessions, where the agent's session id legitimately changes after launch.)

Why it matters

External integrations that correlate an hcom instance with the live agent session by session_id — e.g. mapping "which running session is this hcom peer" for downstream identity/permission checks — can't reconcile the two: the id from hcom list --json doesn't match the id the session reports about itself at runtime, so the correlation silently fails for any resumed/forked session.

Question (intent)

Before proposing anything, I'd like to know your intent:

1. Is session_id in hcom list --json meant to be the launch-time / PTY-bound identity, deliberately distinct from the agent's current session-file id? Or is it intended to track the live session and simply not being updated on resume/fork?
2. If it is meant to be the launch-time id, would you be open to hcom list --json also exposing the current/live session id (an extra field), or providing some mapping between the two, so downstream tools can align on the id the session actually reports about itself?

Happy to help reproduce further or test a direction once you've weighed in on the intended semantics. I'm intentionally not proposing a fix here since it touches core identity semantics.

🤖 Generated with Claude Code

[zane668]

I wrote the durable-identity proposal as two focused RFCs so the primitive and resume policy can be discussed independently: #86 defines the principal ID and mapping surface; #87 adds tracked-resume retention and depends on #86. Both explicitly keep fork, adoption, name reclaim, and vanilla restart outside automatic inheritance.