[QUESTION] Mods: protected existing-session pairing, runtime facts and hook interposition

Status Open
Reported on v2.1.291
Maintainer reply None cached
Activity 0 comments · opened Oct 15, 2026

We are investigating a local application's explicit, connect-once attachment to
an already-running interactive Claude Code conversation via an ordinary Mod.
Pairing would authenticate reciprocal public keys; it would not authorize messages
or change tool permissions. We are not asking to bypass managed policy.

In generated 2.1.291 types and the public docs:

  • process.spawn requests/output can be interposed on by other Mods, so helper

stdout cannot by itself authenticate the helper or its native parent;

  • session.id/root/repo/version are method-hook-facing;
  • ui.ask goes through tool/render hooks, and pane input/press hooks can run before

callbacks;

  • next.origin and next.trace provide host-owned per-dispatch facts, but do not

appear to expose a complete native-root enrollment or current-profile receipt
directly to an external application.

Is there a supported path for an ordinary Mod to:

  1. Keep its pairing key inside the loaded Mod (for example with crypto.subtle)

and let the user authenticate that root for the exact existing session on a
genuine comparison/confirmation surface, despite permitted hook interposition?

  1. Obtain authoritative current session/engine/checkout and complete loaded-hook

profile/generation facts, or a protected owning channel for a native helper,
without trusting a socket-fetched root or self-reported metadata?

  1. Reliably fence that enrollment when the module/worker/profile/session changes,

including reload, /clear and resume, without adopting a replacement by labels?

If the supported contract instead requires trusting the entire loaded hook chain
or a managed deployment, please clarify that requirement and how a Mod can verify
it for an already-running session. Is there a documented way to use the core
entries in next.trace for these scope facts, without skipping policy hooks?

This is separate from engine-owned submit→turn association in #101742. We are not
inferring native receipt from submission return/timing/body equality, and are not
requesting transcript access, credential access, permission answers, a second
conversation, or a model request. We have not established an ordinary Mod bootstrap
contract from these docs; this is a question, not an impossibility claim.

View original on GitHub ↗