Runtime Control API / CLI for Zed (external automation, mobile control, hardware integrations)

[anthonypelletier]

What are you proposing?

A runtime control API for Zed — a way for an already-running Zed instance to be inspected and driven programmatically from outside the editor process, beyond what the current CLI offers (which is limited to "open a file" / "wait for close").

Concretely, this would mean exposing a local RPC surface (e.g. a Unix socket / named pipe / localhost WebSocket) that lets an external process:

• Query editor state: open workspaces, open buffers/tabs, active file, cursor/selection, diagnostics, git status
• Query agent state: current status of any running agent (e.g. running, idle, waiting_for_permission, waiting_for_input/asking a question, error, done), plus enough context to act on it (which permission is being asked, what the question is)
• Trigger actions: open a file, run a task, focus a pane, switch tabs, open/close the terminal, run a command from the command palette
• Respond to an agent on its behalf: grant/deny a pending permission request, answer a pending question
• Send input to a running terminal panel and read its output
• Subscribe to state-change events (file opened/saved, task finished, diff ready, agent status changed, agent turn finished, etc.)

This is different from ACP: ACP governs how an agent plugs into Zed's Agent Panel to edit code. This proposal is about letting an external controller (not necessarily an AI agent) drive and observe the editor itself.

Why does this matter?

Zed's current CLI (zed file.txt, --wait, --diff, --add) is one-directional and process-spawning — it can open things in Zed, but there's no way for an external tool to talk to a Zed instance that's already running, query its state, or push events into it. ACP is scoped to agent-editor interaction inside the Agent Panel, and Zed's real-time collaboration RPC is currently closed to Zed clients only, so neither is really meant to be a general "outside world → editor" control channel.

This would unlock:

1. Mobile companion control — a phone app that can see what's open in Zed, glance at build/test status, get notified the moment an agent is idle, waiting for a permission, or asking a question, and answer or approve/reject right from the notification — without needing a full remote desktop session.
2. Hardware integrations — Stream Deck / macro-pad / MIDI-controller style bindings to trigger Zed actions (run task, switch branch, toggle terminal, accept/reject diff, approve a pending agent permission) from physical hardware, the same way people already do for OBS or DAWs. A button or LED could reflect live agent status (idle vs. running vs. waiting on you).
3. Scripting and automation — CI-adjacent or personal automation scripts that open specific files/diffs in a running Zed window, or drive it as part of a larger workflow, instead of shelling out blind commands.
4. Third-party integrations — dashboards, notification tools, or other apps that want to reflect or react to editor state in real time.

Are there any examples or context?

• Neovim's --listen / RPC API and nvim --remote
• Emacs' emacsclient / server-eval model
• VS Code's (more limited) CLI + extension-based remote control
• OnOrca's orca CLI, which talks to a running Orca runtime over a local interface to inspect worktrees, launch and read/send terminals, open files, and drive the app's embedded browser — close to the shape of API being proposed here, just for a different tool
• Two related discussions already on this repo that point at the same underlying gap:
  • #49313 – "Mobile App to control my Agents panel runs remotely" — asks for mobile control specifically of the Agent Panel. This proposal would generalize that: a runtime API that exposes editor state and actions broadly (not just agent runs) is what a mobile companion app would actually need to be built on top of.
  • #50999 – "Cross-Editor Collaboration Protocol & Extension API" — asks to open up Zed's internal Protobuf RPC so external clients can participate in collaboration sessions. Different motivation (cross-editor pairing), but the same underlying idea: expose a documented RPC surface to processes outside Zed instead of keeping it fully internal.
• In the absence of any official interface, people are already building this themselves by brute force: MarlenaMakosza/Stremdeck-zed is a Stream Deck plugin that drives Zed through a small local HTTP server that simulates keystrokes. It works, but it's a workaround — it can only trigger keybindings blindly and can't read any editor state back. A real runtime API would make this kind of integration reliable and let it react to what's actually happening in the editor instead of firing inputs open-loop.

Possible approach

• Even a minimal v1 would be enough to unblock the community: a read/trigger/subscribe surface over a local socket (state query + a small set of trigger actions + event subscription), gated behind a setting or a permission prompt so it's opt-in and not a default-on attack surface.
• Agent status/permission/question handling could reuse whatever internal state model already backs the Agent Panel UI, just exposed read/write through the same socket rather than building a parallel system.
• This doesn't need to ship as one big feature — it could start scoped (e.g. read-only state + agent status first, then actions, then terminal I/O) and grow incrementally based on what integrations the community actually builds.