MCP Bridge

The DAEMON Bridge is an MCP server that lets agents in other tools, such as Claude Code and Cursor, call a small allowlisted set of DAEMON's tools. The agent proposes; DAEMON decides. Wallet keys never leave DAEMON, and every write or sensitive action pauses on an approval card inside the app.

The bridge requires the DAEMON app to be running. External agents can list tools while it is closed, but every call is executed inside DAEMON, so a closed app means no execution and no approvals.

What the bridge is#

Model Context Protocol (MCP) is how coding agents discover and call external tools. The DAEMON Bridge packages a curated slice of DAEMON's internal tool catalog as a standard MCP server, so an agent running in another client can read project state, manage project memory, inspect wallets, or preflight a token launch without DAEMON giving up control of any of it.

The key property: the external agent can only propose actions. DAEMON's risk gating decides what auto-runs and what stops for a human. Approvals can only be resolved by you, inside the DAEMON app. The bridge process that other tools spawn holds no wallet keys and cannot approve anything.

Agent proposes

Claude Code, Cursor, or any MCP client calls a bridge tool like read_wallet or remember_fact with typed input.

DAEMON decides

Read tools auto-run. Write tools raise an approval card in DAEMON. Sensitive tools keep typed confirmation. Rejections and timeouts return to the agent as errors.

Keys stay home

Signing keys and API keys live encrypted inside DAEMON's main process. The bridge exposes actions, never key material.

Small surface

16 allowlisted tools across four domains: wallet, launch, memory, and project files. Nothing else in DAEMON is reachable over the bridge.

Architecture and security model#

The bridge is two pieces: a stdio shim that MCP clients spawn, and a loopback HTTP server inside the running DAEMON app.

Call path

MCP client (Claude Code, Cursor, ...)
  |  spawns
  v
daemon-bridge-shim.mjs          stdio MCP server, holds no secrets
  |  HTTP 127.0.0.1:7337 + bearer token
  v
DAEMON app (main process)
  1. allowlist + capability-pack filter
  2. risk gate: read auto-runs / write approves / sensitive typed-confirm
  3. approval card rendered in DAEMON's UI
  4. tool executes with DAEMON's own services

Transport and authentication

Loopback only. The bridge server binds 127.0.0.1 (port 7337 by default, override with DAEMON_BRIDGE_PORT). Requests from any non-loopback address are refused.
Bearer token. The shim authenticates with a random 256-bit token DAEMON writes to a bridge.json file in its app-data directory. Comparison is constant-time, and failed auth returns a generic 404 so the server does not advertise itself to local port scanners.
No browser access. Requests carrying an Origin header are rejected, so web pages cannot reach the bridge even from localhost.
Token rotation. Rotate the token any time from Settings, Integrations, DAEMON Bridge. Shims re-read bridge.json on every call, so rotation does not require reconfiguring clients.

Risk-tiered approval

Bridge calls run through the same execution path as DAEMON's built-in ARIA operator, with approval always required for anything beyond a read. Each tool carries a risk tier:

Tier	Behavior over the bridge
read	Auto-runs. No prompt.
write	Pauses on an approval card inside DAEMON. The app window is focused so you see it.
sensitive	Same approval flow, reserved for key-touching and on-chain actions such as wallet creation and token launches.

Approvals can only be resolved from DAEMON's own window. The shim, and the agent behind it, cannot approve their own calls.
Unanswered approvals time out (120 seconds by default) and the call returns a timeout error to the agent.
At most 4 bridge calls run concurrently; extra calls are rejected with a busy error rather than queued silently.

File-read safety

The file tools are scoped to a project registered in DAEMON and hardened against the ways a read tool can leak secrets:

Secret files are denied. Reads of .env and variants, *.pem, *.key, key and keypair JSON files, wallet JSON files, SSH keys, and anything with "secret" in the name are refused by basename, even inside the project root.
Paths cannot escape the project. Containment is enforced against the real path, so a symlink inside the project pointing outside of it is also refused.
Project scoping is explicit. File and memory tools resolve the caller's working directory against projects registered in DAEMON. A folder that is not a DAEMON project gets no file access.

What the shim can and cannot do

Can	Cannot
List the allowlisted tools and forward calls to the local DAEMON app	Approve, auto-confirm, or bypass any approval
Read the bearer token and port from bridge.json	Access wallet keys, seed phrases, or stored API keys
Report progress while an approval is pending	Call tools outside the allowlist, or tools of a disabled capability pack
Cache the tool list for offline listing	Reach DAEMON from another machine (loopback only)

Capabilities#

Bridge v1 exposes exactly 16 tools across four domains. The wallet, launch, and memory domains follow DAEMON's capability packs: disable a pack in DAEMON and its bridge tools disappear from the tool list. Everything else in DAEMON stays internal.

Wallet

Tool	What it does	Risk
`read_wallet`	Read wallet balances and holdings for the active project.	read
`generate_wallet`	Generate a new named signing wallet inside DAEMON.	sensitive
`set_default_wallet`	Set the default DAEMON wallet.	sensitive
`assign_project_wallet`	Assign a wallet to a project.	sensitive
`store_helius_key`	Store a Helius API key for RPC and data access.	sensitive

Launch

Tool	What it does	Risk
`tokenlaunch_list_launchpads`	List available token launchpads and whether each is enabled.	read
`tokenlaunch_preflight`	Validate a launch config and estimate cost before anything is spent.	read
`tokenlaunch_create`	Launch a token on-chain. Spends SOL, irreversible, always requires your approval in DAEMON.	sensitive

Memory

Tool	What it does	Risk
`remember_fact`	Store a durable project fact (decision, constraint, command). Secrets are rejected.	write
`recall_memories`	List the facts stored for the project.	read
`forget_memory`	Archive a stored fact (reversible).	write
`update_memory`	Correct a stored fact's title or value.	write

Project files

Tool	What it does	Risk
`read_project_status`	Summary of the active project: wallet, enabled integrations, network.	read
`list_project_tree`	List files and folders under the project root.	read
`read_file`	Read a text file inside the project (secret files denied).	read
`search_files`	Search project text files for a literal query.	read

Setup#

The shim is not on npm yet; today it ships with DAEMON. Packaged builds include it at resources/bridge/daemon-bridge-shim.mjs inside the install directory, and a source checkout builds it with pnpm run build:bridge (output: dist-bridge/daemon-bridge-shim.mjs). The shim runs on your system Node (18 or newer).

Recommended: one click from DAEMON

Open your project in DAEMON.
Go to Settings, Integrations, DAEMON Bridge. Confirm the status dot shows the bridge listening on 127.0.0.1:7337.
Click Enable for active project. DAEMON writes a daemon-bridge entry into the project's .mcp.json with the correct shim path.
Open the same folder in Claude Code. It reads .mcp.json and the DAEMON tools appear.

Manual: Claude Code

Claude Code reads project-scoped MCP servers from .mcp.json in the project root. Point args at the shim path on your machine:

.mcp.json

{
  "mcpServers": {
    "daemon-bridge": {
      "command": "node",
      "args": ["C:\\path\\to\\daemon-bridge-shim.mjs"]
    }
  }
}

The shim discovers the running app automatically by reading bridge.json from DAEMON's app-data directory (on Windows %APPDATA%\daemon\bridge\bridge.json, on macOS ~/Library/Application Support/daemon/bridge/bridge.json, on Linux ~/.config/daemon/bridge/bridge.json). If your install uses a different app-data folder, set DAEMON_BRIDGE_INFO to the file's full path in the env block.

Manual: Cursor

Cursor uses the same shape in .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

.cursor/mcp.json

{
  "mcpServers": {
    "daemon-bridge": {
      "command": "node",
      "args": ["C:\\path\\to\\daemon-bridge-shim.mjs"]
    }
  }
}

For file and memory tools, the folder you open in your MCP client must also be registered as a project in DAEMON. The bridge matches the caller's working directory against DAEMON's project list and refuses project-scoped tools when nothing matches.

Planned

An npm package for the shim, so clients can use npx instead of a local file path. Until then, build from source or use the copy shipped with the app.

Troubleshooting#

Symptom	Cause and fix
“DAEMON is not running”	The app is closed or the shim cannot find bridge.json. Open DAEMON, then retry. If DAEMON runs under a nonstandard app-data path, set DAEMON_BRIDGE_INFO to the bridge.json path.
“Bridge token mismatch”	The token was rotated or bridge.json is stale. In DAEMON, open Settings, Integrations, DAEMON Bridge and re-enable the project (or just retry: shims re-read the token per call).
Approval card never appears	Approvals render only in the running DAEMON app, which focuses its window when one arrives. If DAEMON is closed the call fails; if you miss the card, the call times out after about 120 seconds and the agent sees a timeout error.
Port 7337 in use	Another process owns the port. DAEMON reports this in the Bridge settings section; set DAEMON_BRIDGE_PORT to a free port before starting DAEMON. If a second DAEMON instance owns it, close one.
“Too many concurrent bridge calls”	The bridge caps in-flight calls at 4. Let pending calls (often pending approvals) finish, then retry.
“No DAEMON project matches”	The agent's working directory is not a registered DAEMON project. Add the folder as a project in DAEMON first.
“Tool unavailable: the ... pack is disabled”	The capability pack backing that tool is turned off in DAEMON. Re-enable it in Settings.
“Refusing to read a secret-bearing file”	Working as intended. .env files, key material, and wallet files are never readable over the bridge.

FAQ#

Does the external agent ever see my keys?

No. Keys are stored encrypted inside DAEMON and used only by DAEMON's own services. The bridge returns action results (balances, summaries, transaction outcomes), not key material, and the file tools refuse key and env files outright.

Can an agent approve its own actions?

No. The approval channel is wired to DAEMON's renderer and checks the sender, so only a click inside the DAEMON window can resolve an approval. The shim has no approval API at all.

Can another app on my machine call the bridge?

Only if it presents the bearer token from your user profile's bridge.json. Unauthenticated requests get a generic 404, browser-originated requests are rejected, and the server never listens beyond loopback. You can rotate the token at any time.

Does this work while DAEMON is closed?

Tool listing works from a cached snapshot so the MCP handshake succeeds, but every call needs the running app. Calls made while DAEMON is closed return an error telling the agent to have you open the app.