Subshell Docs
Agents

Overview

Agents are plugins: what that means for what you can launch, where binaries live, and who decides the set.

Every agent Subshell can put in a pane (and the plain Terminal) is a plugin. A plugin teaches Subshell how to drive one program: how to find it, what command line starts it, how to wire in the tools that make a subshell more than a terminal, and which settings are worth offering you. The program itself is the agent's own CLI, installed the ordinary way; the plugin never ships it, only drives it.

The control plane owns the set

Plugins are installed once, on the control plane, into a single store under its data directory. One install arms every node: a node holds nothing plugin-shaped and simply executes the command line the plane built for the launch. Because installing a plugin runs third-party code inside the control plane's own process, installing, enabling, and uninstalling are admin acts, made at Settings → Plugins. See The Plugin Registry.

Whether you can launch an agent on a machine is the answer to two separate questions:

  • Does this instance offer the plugin? It must be installed in the store and enabled. Enablement is instance-wide: toggling a plugin off hides it from every launch picker at once, and there is no per-node switch.
  • Does this machine have the binary? Detection is the plane asking and the machine answering: the launch page, the Re-check button, and the launch itself each trigger a probe for the agent's program. It is never a background scan a node runs on its own.

A launch picker therefore offers only what that host actually has, per person: a plugin installed and enabled on the instance, with its binary found on the machine you are pointing at.

The six built-ins

Six harness plugins ship with Subshell and are seeded into the store on first boot:

  • Terminal: a plain shell in a pane. No agent, nothing to detect beyond the shell itself, and nothing to install.
  • Claude Code: Anthropic's agentic coding CLI. The richest integration: per-launch MCP wiring, notification hooks, and conversation resume across restarts.
  • OpenCode: the open-source omnichannel coding CLI. MCP wiring arrives as a merged config layer, so your own opencode config is never touched.
  • Codex: OpenAI's coding CLI. MCP wiring rides per-invocation config overrides, and its user state (~/.codex) is left exactly as you have it.
  • Hermes Agent: Nous Research's open agent CLI. MCP is registered once per machine with a command the preset editor hands you.
  • pi: the minimal pi.dev harness. MCP comes from a community adapter extension, installed once per machine; the editor shows both steps.

The split that matters day to day: Claude Code, OpenCode, and Codex wire Subshell's cross-subshell tools in automatically at every launch, while Hermes and pi use a config format with no per-launch override, so they ask for a one-time registration instead. All of them reach the same MCP server; the difference is only how many times you set it up.

Beyond the built-ins

Every built-in is also an npm package (@subshell-ai/plugin-<id>), and the same Settings → Plugins door installs third-party plugins from a registry. The plugin API they are written against is public; Writing a Harness Plugin covers what a plugin can do.

If a picker shows "program not found" for a plugin that is installed, the fix is the binary, not the plugin; see Installing Agent CLIs.

See also

  • The Plugin Registry: the store, the admin gate, and what registry installs verify
  • Installing Agent CLIs: getting the agent binaries onto the control-plane host
  • Nodes: the machines that actually run the panes, and Re-check
  • Presets: saved launch configurations per harness
Edit on GitHub

Last updated on

On this page