A trigger-woken session runs without MCP connectors — the only channel in strips the channel out

[bdelanghe]

Surfaced while working #337/#338. It reframes the dogfood result, so it wants its own number rather than a paragraph inside either.

The finding

create_trigger is the only way we can reach another live session — it pushes a prompt into it and wakes it (persistent_session_id). A session woken that way runs without any mcp__<server>__* tools.

The tool said so itself, unprompted, on the return of a create_trigger call:

this trigger stores no MCP connectors, so the sessions it fires will run without connector (mcp__<server>__*) tools. Connectors on triggers created via this tool are limited to those the calling session itself holds; this call had none to pass through (no session context, or no passable connector grants). If the routine needs connectors, create it from a session that holds them, or ask the user to create it from the claude.ai routines UI.

Why it matters

#337 recorded that a checkout-less session could not report its findings to GitHub, and attributed it to the session being bare. That attribution is wrong, or at least incomplete. The missing GitHub tool is a property of being woken by a trigger, not of having no repos attached.

Measured, both sessions in #337:

	v1 session_015MHtz7BxTVDRuvvG5o7rGi	v2 session_01EhoqH39bRLv1c4NLiRFyvT
asked to comment on #337	yes, via trigger trig_012uTx3LpJZ5mXhpTsFtWLfF	yes, in its seed prompt
trigger fired	run_once_fired, last_fired_at 2026-09-01T13:21:08Z	n/a
woke and worked	yes — output tokens 2,549 → 6,862	yes
comment posted	none	none
its own status line	measured 5 questions: session ID, repos, env vars, network tools, GitHub access	cannot post findings; no GitHub tool + no relay bearer

v1 spent a full turn on the follow-up and produced nothing on the issue. Its status line changed to name the five questions it had measured — so it did the work, and the answers went nowhere.

The shape

The one channel in guarantees no channel out.

• We can only reach a session by pushing (create_trigger); there is no pull (read_code_session: a Claude Code session URL should read like a share link #338).
• A pushed session has no connectors, so it cannot post, comment, or call any MCP door.
• Its entire outbound bandwidth is post_turn_summary.status_detail — measured at roughly 44–80 characters, and it is a generated summary, not text the session controls.

That is a closed loop, and it is why #337's report channel could never have worked, regardless of what the session was told to do.

What this changes

• Dogfood: does a checkout-less session actually get the verbs? #337: measurement 6's attribution needs correcting — "bare session has no channel out" → "trigger-woken session has no channel out". Being bare is not the operative cause. Its earlier comment predates this finding.
• read_code_session: a Claude Code session URL should read like a share link #338 door (c): strengthened. If a session must publish its own Graph, it cannot be asked to at wake time by a trigger — the trigger cannot hand it the tools to do so. Publishing has to be armed at session start (bootstrap), not requested later.
• Dogfood: does a checkout-less session actually get the verbs? #337 fix 2 / the bearer work: the bearer cannot arrive via a trigger either. It has to be present from session start, which points at boot.sh / the session-start dispatcher rather than any push-time mechanism.

Open questions

• The warning says connectors can ride a trigger when "created from a session that holds them" — this session holds the GitHub connector and the pass-through still came back empty. Why? Is it a created_via: meta_mcp limitation specifically?
• Does the claude.ai routines UI genuinely attach connectors where the MCP tool cannot? The warning asserts it; unverified.
• Is post_turn_summary steerable at all — can a session shape it reliably enough to be a deliberate (if tiny) return channel, or is it purely generated? A test is armed as of filing.

Related: #337, #338.

[bdelanghe]

Confirmed from both ends: cross-session messaging works only by trigger-binding, and it is one-directional

This issue's original claim — "a trigger-woken session runs with no mcp__* connectors" — was already corrected once (P6 called mcp__bounded-verbs__read_session successfully on a trigger-woken turn). Here is the accurate version, measured from the child's side this time.

A probe tried to reach its parent and reported the attempt verbatim:

SendMessage → {"success":false,"message":"No agent named 'session_01TzRQ…' is reachable."} — ListAgents shows no reachable peers at all, and there is no send_message tool in my surface (ToolSearch for it returns no match, despite create_session's own description telling me to "combine with send_message").

The path that worked: a poke-only trigger bound to the parent, then fire_trigger. The message landed as a user turn there.

Both halves confirmed independently: the parent's ListAgents also reports no reachable peers, and the message did arrive here as an ordinary user turn.

What the mechanism actually is

SendMessage / ListAgents	unusable across cloud sessions — different containers, no peers ever listed
send_message	absent from the surface, though create_session's own description instructs callers to use it
trigger bound to a session + fire_trigger	works — delivers as a user turn

So cross-session messaging exists, but only in a shape nobody documents:

• one-directional. The sender cannot receive a reply. The probe said so plainly: "I have no way to poll for its answer; a reply would have to arrive as a new turn here." It asked whether to archive itself and could not learn the answer — the parent had in fact already archived it minutes earlier.
• it leaves an artifact. Every message creates a persistent routine. The one that carried this report (trig_01ARyi5joHwiqXk54bYPJC1Z) had no schedule, so it would never fire again, but it sat there as scaffolding until deleted by hand. A fan-out of N probes leaves N stale routines.
• it needs the recipient's session id, which a child gets from get_session → parent_session_id.

Why this matters beyond plumbing

.github#337 keeps rediscovering the same asymmetry, and this is its cleanest statement: reporting outward is solved; asking is not.

That probe had a working outbound channel — it posted to the pathbase door successfully, HTTP 201, no classifier block. It still could not ask a one-word question and get an answer. A door that carries findings out is not a conversation.

Anything designed around "the child will check with the parent" is designed around a capability that does not exist. Either the child decides alone, or the work stops until a human looks — which is exactly the state four cold-start probes ended in tonight, three of them blocked on questions only a human could answer.

For the P6 harness specifically

If probes are to report back as a matter of course, this is worth fixing before the repo-cloned re-run the probe recommended. Otherwise every run costs a hand-cleaned routine, and any probe that needs a decision mid-run stalls.

Corrects this issue's causal claim a second time. Related: #337, #338 (the pull-path gap this mirrors), .github-private#514.

---

Generated by Claude Code