Beyond the Core: MCP, Extensions, Delegation, and Remote Use

Reasonix can grow in several directions, but an external tool, a code extension, a child agent, an editor connection, and a remote host do not create the same kind of trust. This chapter compares those paths by capability, state ownership, transport, and recovery so you can decide what to add without mistaking connectivity for containment. The useful question is not “which integration has the most features?” but “what crosses the host boundary, and who remains responsible for the effect?”

A local file edit is visible to Reasonix’s structured writer and workspace rules. An MCP server may keep a browser session or change an external service. A code extension may be able to bypass the ordinary Sandbox by design. A child agent may have a narrow context but still need a write claim. ACP can route work through an editor’s unsaved buffer, while Remote SSH moves the agent and files to another machine. These are different boundary changes, even when they all appear in one user interface.

flowchart TD C["Reasonix controller and stable capability proxy"] --> M["MCP and plugins: installed-server trust; process and session state"] C --> X["Code extension: out-of-process full trust; atomic runtime generation"] C --> D["Subagent and fleet: explicit context capsule; write claim; scheduler"] C --> A["ACP and editor: client buffers and terminal capabilities"] C --> R["Remote SSH: remote agent and files; local tunnel; credential modes"] M --> MT["Workflow metadata is not containment"] X --> XT["Manifest and protocol checks do not remove full trust"] D --> DT["Scope buys parallelism; missing scope retains broad ownership"] A --> AT["Session identity and client capability negotiation"] R --> RT["Remote writer ownership and reconnect boundaries"]

MCP extends capability, not the Sandbox

Reasonix uses MCP as a protocol channel for tools, prompts, and resources. It supports local stdio servers, Streamable HTTP, and the legacy SSE transport. A configured server has a lifecycle: initialize, announce readiness, list tools, and then receive calls. A persistent stdio process can retain state between calls, which is essential for a browser or another tool whose meaning depends on the active session.

That persistence is a feature and a risk. Two calls to the same stateful server do not necessarily behave like two independent reads. One call can open a page or select a tab; the next call sees that changed server state. Reasonix therefore keeps a shared server session and can apply a server-level serial policy when interleaving would be unsafe. A server that is read-only with respect to local files can still be stateful with respect to its own world.

MCP tools enter Reasonix through a stable capability proxy rather than expanding the provider-visible tool schema every time a server connects. The model can list or inspect available capabilities, call one, or decline it through the proxy. This keeps the top-level request shape stable for prompt-cache purposes. It also gives the host a final place to re-check runtime enablement, authorization, the exact Host connection identity, and live safety metadata immediately before dispatch.

The proxy is not a trust substitute. Installation or project declaration is the authorization decision for the server. Reasonix keeps explicit deny rules and process boundaries, but it trusts an installed server’s readOnlyHint and destructiveHint enough to guide scheduling, Plan behavior, and strict read-only subagents. A dedicated Planner can use authorized, non-destructive MCP even when a server omits readOnlyHint; a strict read-only child remains narrower. These are workflow policies for a trusted integration, not a containment boundary against a malicious server.

The same principle explains ambiguous reconnects. If an established server disconnects with a clear session failure, Reasonix can rebuild the session and replay a call under bounded rules.