Get Started Free

Claude Code: connection and validation

Estimated reading time: 4 minutes

Limited coverage · Reviewed 2026-09-07

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

Connect Claude Code through the managed companion

Create a workspace for Claude Code Open Claude Code 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 Claude Code 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 Claude Code configuration into the project’s .mcp.json. Start from the configured host environment and approve the server in the normal /mcp interface. No bypass flag is supplied.
  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 an isolated project and synthetic credentials. No model account, external OAuth provider or production Claude Code 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 claude-code.mcp.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 claude-code.mcp.json into the project's .mcp.json. Set the public endpoint and pre-registered public client ID in the two environment variables above. The example pins callback port 33117; register the exact URI emitted by your installed version. Current documentation uses http://localhost:33117/callback; it notes a 127.0.0.1 regression in 2.1.229. Do not use a mismatched registered URI. Run /mcp to approve the project connection and authenticate. Keep normal tool confirmations enabled. Do not put a bearer token in headers or a client secret in this project file.

Primary contract: https://code.claude.com/docs/en/mcp (read 2026-09-06). This is a management MCP connection, not general interception or a published plugin.

Validation: Claude Code 2.1.202 accepted the HTTP/OAuth configuration through mcp add-json and produced matching project configuration in an isolated directory. No user credentials or live MCP authentication were used.

Local SDK setup · Inspect evidence · Runtime catalog