Get Started Free

OpenCode: connection and validation

Estimated reading time: 4 minutes

Limited coverage · Reviewed 2026-09-07

OpenCode 1.18.29 authenticates and discovers the runnable managed MCP companion. Explicit prepare, owned checkpoint and approved resume pass transport and durable-restart acceptance.

Connect OpenCode through the managed companion

Create a workspace for OpenCode Open OpenCode setup · Start with the free sample

  1. Create your free workspace and verify your email. On the dashboard, run the local allow/block sample and inspect the saved audit and actual signing status. This requires no model or external target; it does not connect a client or create independently verified proof.
  2. Return to your saved OpenCode setup. Create its real managed-mcp installation, then download the configuration and local package commands bound to that installation. Agent association is optional. Configuration starts read-only.
  3. Load the creator’s scoped API credential on the controlled companion host and run the one-use connection challenge there. Credentials never belong in a public workflow, model prompt or exported configuration. Recorded credential proof does not attest native installation or a target effect.
  4. Merge the local OpenCode configuration, put the installed companion CLI on the actual client process PATH, then inspect opencode mcp list. The configuration keeps the Praesidia tool permission prompt; other native tools are unaffected.
  5. Inspect connection from the native client. To execute, bind an authorized registered target and obtain its public signing key independently. Preparation stops for a different human reviewer. Resume needs the exact stored approval, request commitment and explicit confirmation; ambiguous attempts must not be retried blindly.
  6. Refresh the workspace and inspect the server-returned action bound to this installation. A successful connection or copied guide is not execution evidence.

For n8n, Dify and Langflow, the operator supplies a reachable authenticated HTTPS companion endpoint and a separate companion bearer in the client secret store. One companion has one creator and installation; workflow or chat identities do not establish separate delegated users.

Exact local package, credential and native client instructions · Read-only public configuration template

Source paths in those instructions refer to the matching checkout supplied by your deployment operator. No public package or marketplace release is assumed. Free setup remains available; protected execution requires proof.actions and the appropriate role and scopes. Payments are currently unavailable. Provider usage may have separate charges.

Connection acceptance comes before a coverage claim

This distribution profile is separate from native runtime enforcement. Check the exact client version, transport, authentication, and tool surface with the operator. No marketplace listing or automatic interception is implied.

Setup instructions for this profile come from the SDK documentation your deployment operator provides.

  1. Configure a dedicated test connection with minimum scopes. Never paste a runtime secret into a public workflow or repository.
  2. Discover the tools and allow only the intended tool set. Confirm the exact transport supported by your installed client.
  3. Make one harmless managed call. Check denial and revoked credentials; a client that continues after a failed policy hook does not enforce that hook.
  4. Inspect the action ID in Praesidia. Report whether the test covered a managed call, native interception, or observation only.
  • Only explicit tools on the configured Praesidia companion are governed; unrelated native tools remain outside this boundary.
  • Packages are local release candidates. Real API/backend datastore installation-bound acceptance is pending the combined customer run; publication and deployed customer workspaces need separate acceptance.
  • One companion uses one operator-configured creator and installation. It does not infer end-user delegation from a workflow or chat identity.
  • The released CLI discovery test used owned local configuration and synthetic credentials. No model-driven tool choice, external OAuth provider or production OpenCode host was exercised.

Alternative: earlier narrow source example

This separate example is not the managed companion setup above and does not establish an installation-bound connection. Preserve its narrower scope when evaluating it.

Download opencode.json · All source instructions

Provide your operator's endpoint, registration, and credential reference. No secret belongs in these files. The connection exposes the configured MCP tools; it does not intercept unrelated native tools. Configuration and isolated fixture checks do not establish a completed client authentication run.

Set up this alternative

Merge opencode.json into a project's OpenCode configuration. Provide the actual MCP endpoint and a pre-registered public client ID using PRAESIDIA_MCP_URL and PRAESIDIA_MCP_CLIENT_ID. No token or client secret belongs in the file. The operator must register the exact callback URI used by the installed client and allow the MCP resource and requested scope. Use opencode mcp auth praesidia and opencode mcp list to inspect authentication and discovery. The template asks before Praesidia tools; it does not block unrelated native tools.

Primary contract: https://opencode.ai/docs/mcp-servers/ (read 2026-09-06). Client authentication and transport require version-specific acceptance with the actual deployment.

Validation: the public OpenCode JSON Schema accepted this template on 2026-09-06. This checks configuration structure, not a completed OAuth exchange.

Local SDK setup · Inspect evidence · Runtime catalog