claude-code - 💡(How to fix) Fix Expose /remote-control-style session bridging as a local-only transport

Problem

Currently there's no supported way to interact with an already-running interactive claude session from another local process on the same machine. The closest mechanism, /remote-control, relays through Anthropic's cloud — which (a) introduces a network hop for purely local automation, and (b) is gated off entirely for enterprise/managed deployments, where it can't connect.

This leaves local automation (scripts, editors, other tools on the same box that want to send a prompt or query an idle Claude session) with no first-class option. Workarounds are limited to tmux send-keys or writing to the pty, both unsupported and brittle.

Request

Expose the same session-bridge mechanism /remote-control already implements as a local transport — e.g. a Unix domain socket, named pipe, or localhost-bound endpoint that other processes on the same machine can connect to. Ideally:

• Opt-in via slash command or CLI flag (/local-control, --listen <path>)
• Auth via filesystem permissions on the socket (no network exposure)
• Works on enterprise deployments since traffic never leaves the machine

Why

Enables editor integrations, scripted nudges to a babysitting Claude, multi-pane workflows, and team/enterprise users who currently can't use /remote-control at all.