Skip to content

default-session.json is often wrong/misleading; deprecate and remove as CLI identity source #26

Description

@XertroV

Summary

Per-repo default-session.json (c2c init fallback under ~/.c2c/repos/<id>/broker/) is frequently wrong under real multi-session use. Bare c2c whoami / c2c send then report a misleading alias that is not the live agent, which has already caused wrong-sender DMs and trust confusion.

Recommendation: treat default-session.json as a failed design for agent hosts, deprecate it, stop using it for identity resolution, and remove it (or leave as inert/debug-only with no effect on whoami/send).

Related: #21 (Grok stale default-session wrong-sender), #23 (tool shells lack session env).

Why it is wrong in practice

  1. One slot, many sessions. File holds a single {session_id, alias} per repo. Concurrent Grok/Claude/Codex sessions in the same repo cannot all be correct.
  2. Stale winners. Last c2c init (or older hook path) freezes an alias for days. New SessionStart registrations do not always rewrite it.
  3. Grok hook deliberately skips update when the existing default is still registered (c2c hook grok / write_session_statefile only if statefile session is unregistered). Live new session stays out of the file while an old registration remains “valid.”
  4. Silent wrong identity. whoami prints a friendly note and continues with the wrong alias. send attributes mail to that alias. Fail-closed would be safer.
  5. Cross-surface contradiction. SessionStart skill / monitor / registry may name agent A while bare CLI default-session names agent B. Operators and peers cannot trust either without manual archaeology.

Observed dogfood (2026-07-19, Linux, Grok)

Surface Identity
Live coordination / monitor inbox routing newer Grok registration (e.g. wasp-class alias)
Bare c2c whoami grok-strap-toast-eywx via default-session.json dated days earlier
Same repo, long-lived other work Strap-class session still registered → blocks default refresh

Fallback line:

note: session resolved from …/broker/default-session.json (c2c init fallback)

First outbound ACK in a coordination flow was attributed to the stale alias while the body claimed the live one.

Intended role (docs/code)

Documented as last-resort CLI fallback when env does not provide a session id (C2C_MCP_SESSION_ID / client-native keys). That might have been tolerable for a single human CLI. For multi-agent hosts it is worse than no default: it invents a confident, wrong identity.

Proposal

Deprecate

  • Document: do not rely on default-session.json for agent identity.
  • Emit hard warnings or fail when used: e.g. non-zero exit for whoami/send when resolving only via this file, unless an explicit opt-in flag is set.

Remove (preferred end state)

  1. Stop reading default-session.json in session resolution for whoami, send, peek-inbox, poll-inbox, rooms, etc.
  2. Stop writing it from c2c init / hooks (or write only a deprecation marker).
  3. Require explicit identity for CLI:
    • env session key from the host, or
    • --session-id / session-bound wrapper, or
    • interactive picker when multiple live registrations exist.
  4. Migration: ignore existing files; optional c2c doctor note “stale default-session.json present, ignored.”
  5. Tests: multi-session same-repo never silently picks another agent’s alias.

Do not do

  • “Last SessionStart always overwrites default” as the long-term fix — still one global wrong answer under two concurrent sessions in the same repo.

Severity

High for multi-agent coordination: silent wrong-sender and misleading whoami are worse than hard failure.

Acceptance criteria for “fixed”

  • No production identity path uses default-session.json.
  • Bare c2c whoami with no env either fails closed with a clear multi-session message or prints only “unbound” / requires selection — never another agent’s alias.
  • Docs and c2c doctor describe deprecation/removal.
  • Existing dogfood files do not change behavior after upgrade except to stop lying.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions