[FEATURE] External wake signal for interactive sessions

This is the same boundary that shows up in mobile/remote control clients: PTY injection is useful as a last-mile escape hatch, but it is not a safe control protocol once a human or another agent can also be typing in that pane.

For remote surfaces I would want a structured ingress with an explicit session id, prompt/action id, and accepted/rejected/applied/failed receipt. I am building Faryo on the narrower tmux-backed side of this problem: keep Claude/Codex/shell in host tmux, but expose phone/browser output, short input, approve/interrupt, and handoff without pretending raw key injection is the whole answer. https://github.com/Snailflyer/faryo

Strong +1 — we hit this exact wall independently. We run a small multi-team agent setup over a self-hosted coordination store, and the missing primitive is precisely this: an external, non-pty way to wake a session when work lands for it. We'd separately compiled the same dead-ends you list (tmux/pty corruption, --resume not re-reading in-memory state, --remote-control being claude.ai/mobile not local IPC, Agent Teams requiring the framework, stream-json only under --print). claude notify --session-id --type wake is exactly the shape we need.

Two things we'd add from our use case:

1. An optional, identifier-only payload. We understand the no-payload stance (the wake mustn't become a prompt-injection vector) and agree the signal must not carry instructions. But a constrained, structured identifier — e.g. a ticket/topic ID the woken session looks up in its own trusted store — would let it act on the specific item that triggered the wake instead of re-scanning everything, without crossing into "instructions from the signal." The ID is a pointer, not content; the session still reads only from its existing trusted sources. (If even an opaque ID is deemed risky, an allowlisted/enum payload would still help.)

1. The exited-session case. --session-id <uuid> --type wake assumes the session is still running. In our setup sessions often exit entirely between work, and we'd want the same trigger to spawn/resume an exited session (its context reconstitutes from our store on cold boot). A companion for "wake or cold-start session X" would cover the gap where the target isn't currently resident.

Either way — this is the highest-leverage missing primitive for multi-session coordination. Happy to share more detail on the workarounds we tried if useful.

you can already do this with the channel feature https://code.claude.com/docs/en/channels-reference

Channels is human↔session over an external chat bridge (and it delivers a message). This is a local, no-payload wake — carries no
content, can't be a prompt-injection vector, woken session reads only its own trusted sources. Complementary, not the same: same "start a turn" effect, opposite security posture.

The exhaustive dead-end list you've compiled is genuinely useful — I went through the same verification circuit independently and arrived at the same conclusions. A few notes from adjacent territory that might be useful here.

The tmux send-keys path is brittle for exactly the reason you name: pty injection corrupts in-flight input from a human typing in the same pane. But there is a second failure mode that's worth naming for the record: even when no human is typing, two agents injecting into the same pane concurrently (a scheduler firing a cron wake at the same moment a user presses enter) can produce interleaved input that the terminal parser sees as a single malformed command. It is a race condition with no lock.

The design you're proposing — a structured external ingress with session-id targeting and a no-payload wake — maps exactly to what an external coordinator process needs. The no-payload part is load-bearing: a wake signal that carries no text sidesteps the prompt-injection risk that makes raw tmux injection legitimately unsafe in shared environments.

One concrete use case that illustrates the gap: I run a Rust process (cron-driven, roughly 20ms per cycle) that dispatches Claude Code agents on a schedule across project namespaces. The coordinator needs to wake a dormant session when a task queue entry lands — not inject a prompt, just start a turn so the session reads its own trusted state files and decides what to do. Today the only path is polling + --print headless mode, which loses the persistent session context that makes long-running agents useful. The wake signal you're proposing would close this gap without opening a prompt-injection surface.

If you're experimenting with the channel feature (as the comment above mentions) as a partial substitute: it solves the "deliver a message" case but not the "start a turn with no injected content" case. The security postures are opposite — channels accept external content, a wake signal explicitly carries none. Both are useful; they address different threat models.

+1 to this feature. The missing primitive is a first-class IPC endpoint, not a workaround on top of the pty.

Author's note: I'm a Korean speaker; I directed this comment and made the calls, and the English was written by the AI I operate (Claude).

Operational data point in support of this request — lessons learned, not an implementation recipe. I'm not a software developer; I run a small renewable-energy company and operate a multi-session, multi-machine agent setup for real business work: roughly a dozen agent sessions across three machines, with our busiest machine's event stream handling a few hundred wake-relevant events on an active day. For the past several weeks, day-to-day coordination has run on a homegrown wake fabric that approximates what this issue asks for.

The shape of the workaround: a local append-only event log per machine; a small classifier routes signals (from our team chat, our issue tracker, or other sessions — chat is just one ingress, not the mechanism) into per-session filtered streams; each interactive session pre-arms an in-session background watcher on its stream, and a matching line starts a turn. Sessions do wake each other today, without pty injection — but only because every session must pre-arm its own listener.

What real use taught us — and why a native primitive is still needed:

1. The listener is lifecycle-fragile. Context compaction and app restarts kill it silently, and a dead listener is indistinguishable from "no news." We ended up building auto-re-arm on session start, liveness checks, and a round-trip verification rule (recovery isn't declared until a wake actually round-trips). A first-class wake endpoint would delete this entire maintenance class.

1. --session-id <uuid> addressing breaks exactly at the cold-start boundary. In sustained operation, sessions get replaced — they die, respawn, or hand over to a successor — and the uuid changes while the session's role persists. Senders addressing a remembered-but-stale uuid was one of our real incident causes; we ended up maintaining a registry that resolves a stable role name to the current session. A native wake API should support stable aliases, or at minimum expose "resolve the current session for name X" as a first-class query. This composes with hechtron's wake-or-cold-start point: after a cold start, the uuid is new — the alias is what survives.

1. The no-payload stance is load-bearing — we pay the payload tax daily. Our streams carry content, and keeping that safe even inside a single trusted team required sender-identity conventions, self-echo suppression, dedup windows, and claim-gates so a passing mention doesn't get treated as a work assignment. In anything less trusted, I wouldn't want content in the wake path at all.

1. +1 to the pointer-ID option (hechtron's #1): we converged on exactly that — routes carry an issue-tracker ID that the woken session looks up in its own trusted store. Pointer-not-content works well in practice.

1. wake-or-cold-start (hechtron's #2) is a real gap: idle sessions get torn down; we maintain a session registry plus respawn glue to cover it. A native "wake, or cold-start session X" would remove that glue too.

1. Rate limiting and coalescing match what we measured: we've had duplicate-wake bursts; a short dedup window (around 10s in our environment) plus turn coalescing is what we ended up needing.

1. Receipts and visibility matter operationally — and silent drop must be impossible. We log every signal decision (delivered/suppressed/deduped), keep wake-triggered turns visible to the human, and when routing can't resolve a recipient we emit a fail-safe alert to a designated session instead of dropping. That audit trail is the only way to tell "no work" from "silent failure." So: accepted/rejected receipts and TUI visibility deserve to stay in the final design, and a signal to a nonexistent or unresolvable session should be an explicit error/receipt — never a silent no-op.

Happy to share more detail on any of the above if useful.

I would keep the wake path as its own ingress event, separate from user prompt submission.

A safe model:

• the wake request authenticates the sender and resolves a stable session alias to the current session id;
• the request carries no free-form text, only an event type and, at most, an opaque work pointer;
• the runtime emits an accepted, rejected, no_target, or deduped receipt before a turn starts;
• the signal-triggered turn runs under a named event class with its own permission profile;
• any side effect still needs the same tool approval and receipt path as a normal turn, or returns no_effect.

Regression cases:

• stale session id maps to no current alias, so the runtime emits a rejected receipt and starts no turn;
• wake accepted but session is not resident, so the runtime either cold-starts under policy or emits explicit no_target, never silent drop;
• duplicate wakes coalesce, but the receipt preserves count and reasons;
• the opaque pointer changes after acceptance, so the runtime creates a new event id instead of reusing authority;
• any payload or text field is present, so strict schema validation rejects it before it can become prompt content;
• a wake turn attempts write or network under a read-only signal profile, so it prompts, blocks, or emits no_effect.

The important boundary is that wake starts an opportunity to observe trusted state; it is not itself authorization to act. Without a typed wake receipt and event-specific authority profile, external coordination collapses into either unsafe pty injection or silent autonomous execution.