A local bridge lets Claude Code and Cursor use KAI, with approval on every change

What the bridge does

As GitHub's listing describes it, this is a plugin for KAI Core, an AI application. It lets other AI agents running on the same computer, such as Claude Code, Claude Desktop or Cursor, use KAI through the Model Context Protocol (MCP). MCP is a shared standard that lets an agent call tools and read data from another program without custom wiring for each pairing.

The plugin has the ID community.mcp-bridge and is at version 0.1.0, so it is early. It needs KAI Core 0.7.17 or later. It uses no outside libraries, only what Node (the JavaScript runtime) already includes, and runs to about 1,400 lines including its settings window and five interface languages.

Why a bridge was needed

An earlier alpha of KAI exposed tasks, chats, documents, keys, memory, teams and the node itself over a local web interface. A separate standalone server then wrapped those for agents. In KAI Core, those features moved into plugins, and they can only be reached through the plugin system's official interface, not over the web.

The author calls that the right design. It means an outside agent gets in only if a person has chosen to install and approve a plugin that opens the door. This bridge is that plugin. It sticks to the documented plugin interface and the local messaging layer between plugins, and it relies on each plugin's own approval dialogs instead of inventing shortcuts around them.

The Assistant plugin keeps its own rule too. It prompts you each time an agent wants a list of conversations or a conversation you have not shared. The bridge does not try to bypass that.

What agents cannot touch

The more telling part is the exclusion list. Agents can see which tools exist but cannot run them, and paid runs are off the table. Everything involving email, calendar and third-party account actions is out, as are the Brain plugin's tool, context, sync and source functions, which would execute tools or fetch from the network. Saving chats or granting write access in Assistant is also blocked, as are wallet, credits and account requests.

The plugin's manifest, the list of permissions it asks the system for, does not even request wallet, account-request, network-fetch or external-desktop permissions. Local model inference is not wrapped either. KAI already offers an OpenAI-compatible interface at 127.0.0.1:41100, so agents can use that directly.

• Allowed with review: listing and loading models, and viewing or changing privacy settings, both through Core's own review step.
• Opt-in sources: documents, workflows, brain, assistant, code and tools, each only if you tick it.

How the limits are tested

Promises in a README are cheap, so the author describes a test suite meant to enforce them. It switches on every source, permits changes, and exercises every tool the bridge offers. It then compares each plugin method that was actually reached with a written allowlist. It also searches the tool code and the manifest for the banned categories.

The packaging script reuses Core's own packing and verification code instead of reimplementing the format. It refuses a signing key kept inside the repository and will not overwrite a version that has already been published. This is the author's description, and we have not audited the code ourselves.

Setting it up, and two caveats

Installation goes through KAI's third-party plugin screen. You pick the signed package, compare the publisher fingerprint with the one in the project page, and accept the full-access notice that every native plugin carries. Then you open MCP Bridge, press Turn on, and tick which sources agents may use. For Claude Code, the window shows a one-line command containing a local address and a secret token. Other clients get a block of JSON instead.

The author flags two behaviors. Requests arriving through the bridge have no window attached, because a remote agent has none, so any plugin that insisted on a window would refuse the request. That is the safe outcome. Also, the confirmation prompt automatically answers no when KAI is hidden in the system tray, so changes an agent asks for only go through while the KAI window is open. The bridge tells the agent this.

Status and what comes next

The project is independent, built against the public beta of KAI Core and its published plugin guide, and the KAI project does not endorse it. It is MIT licensed. The author offers the KAI team three paths: list it as is, adopt it by re-signing under their own key and a new ID, or leave it as a third-party install. Core ties an ID to its first publisher, so adoption means a fresh ID.

Treat it as a small, careful example rather than a finished product. Approval prompts only help if people read them, and a plugin that asks too often trains users to click yes.