Feature request: supported programmatic/local API to deliver a prompt or control command into a running session (session-chaining)

What I'm trying to do

Run long-horizon, multi-session workflows ("chains") where a single goal is pursued across many sessions. At a planned boundary, the current session should hand off to a fresh context automatically — compact or clear, then seed the successor with a prepared brief — so a long build can progress without a human manually driving each transition.

The blocker is the last mile: **there is no supported, first-party way for an authorized local process to deliver a turn or a control command into a specific running session** while preserving the live interactive window.

The specific capability requested

A supported, authenticated, local mechanism (a permission-gated API, a CLI verb, or a documented hook affordance) for an authorized process on the same machine to submit, into a named running session:

1. a user turn (a prepared prompt / handoff brief), and
2. the text-output control commands that already work remotely — /clear, /compact <instructions>, /model <name> —

…without stealing terminal foreground and without ending the interactive session (the human keeps typing in the same window; the new context layers on top).

Why the existing surfaces don't close this

Each of these is close, and the gap between them is exactly the missing piece:

• Remote Control genuinely dispatches /clear, /compact, /model from web/mobile into the same running session — but only the authenticated human can send; there is no programmatic/local entry point.
• SessionStart initialUserMessage can seed the first turn of a (re)starting session — but it only fires at a boundary that something else already triggered; it can't trigger one.
• claude -p --resume / Agent SDK run a turn against a session — but as a separate process, not the same live interactive window a human is watching.
• Cross-session messaging / channels deliver text, but a slash command in that text "arrives as plain text [and] Claude Code never executes it," and messaging isn't available on native Windows.

So: the pieces to advance the same running interactive session programmatically all exist individually, but there is no sanctioned seam that connects them.

Prior issues (this request is recurring)

• #53049 — External message injection API for active sessions — closed DUPLICATE, locked
• #27441 — Inter-agent message injection (external processes → running session) — closed DUPLICATE, locked
• #65586 — Programmatic model switch for a running session (control-plane, not keystroke injection) — closed NOT_PLANNED
• #65606 — RFC: MCP Bidirectional Session Channels — closed COMPLETED

Filing fresh per the auto-lock guidance ("file a new issue and reference this one"). The repeated filings suggest steady demand for an official surface, so users don't resort to brittle terminal-keystroke simulation.

Nice-to-have shape (non-prescriptive)

A permission users opt into (default-off), scoped to same-user local processes, e.g. claude session send <session-id> --text "…" and claude session command <session-id> /compact "<instructions>", returning a structured ack — mirroring what Remote Control already does, but with a local authenticated caller instead of only the web/mobile human.