[Feature]: Self-host daemon: opt-in flag to inherit MCP servers from ~/.claude.json

[JulienMicrofacto]

Deployment type

Self-hosted

What do you want and why?

Related issues

• feat(agents): expose per-agent MCP / connector wiring in UI and CLI #2385 (open) — proposes per-agent UI/CLI surfacing of mcp_config. Explicitly lists “workspace-level default MCPs that all agents inherit” as out of scope. This issue is about a sibling but distinct mechanism, scoped to a single daemon runtime rather than a workspace.
• Claude agents cannot access any MCP servers due to --strict-mcp-config without --mcp-config #1111 (closed) — established the design rationale for --strict-mcp-config (defensive isolation of spawned agents from the outer Claude Code session’s MCP inheritance). This proposal preserves that default and only changes behavior when the daemon owner explicitly opts in.

Use case

I run a self-hosted Multica instance (single-user, dev machine). My MCP servers (Linear, etc.) are already configured in ~/.claude.json via claude mcp add — they work fine in interactive Claude Code sessions on the same machine. When I trigger an agent from the Multica UI that depends on one of those MCPs, the spawned claude runs with --strict-mcp-config and no --mcp-config, so the agent sees zero MCPs.

I traced this through server/pkg/agent/claude.go and the mcp_config plumbing in server/internal/daemon/daemon.go. The capability is wired end-to-end on the backend: the per-agent mcp_config field exists, and if populated, the daemon passes it correctly to claude --mcp-config . The CLI/UI exposure of that field is the gap #2385 addresses.

Why per-agent mcp_config doesn’t fully solve my case

For a self-host single-user setup, the same person owns the machine, the ~/.claude.json, and every agent in the workspace. Mirroring an already-working MCP config into per-agent JSON for each agent that needs it duplicates the source of truth:

If I add a new MCP server, I have to update ~/.claude.json and every agent’s mcp_config.
If I rotate a token (e.g. a Linear API key), I have to update it in both places.
If I create a new agent, I have to remember to copy the relevant MCPs over.
The natural place for the MCP set, on a self-host daemon that I own end-to-end, is the local file I already maintain. The daemon should be allowed to look at it — provided I explicitly say so.

Proposed solution (optional)

Add an opt-in at daemon start time:

multica daemon start --inherit-local-mcp
# or
MULTICA_DAEMON_INHERIT_LOCAL_MCP=1 multica daemon start

Semantics

• Default: unchanged. --strict-mcp-config keeps being passed, agents stay isolated.
• When opt-in is on AND agent's mcp_config is empty: the daemon does not add --strict-mcp-config to the claude invocation, letting claude inherit the daemon machine's ~/.claude.json.
• When opt-in is on AND agent's mcp_config is populated: per-agent config still wins. --mcp-config <path> --strict-mcp-config are emitted, exactly as today. The opt-in is a fallback for unconfigured agents, not an override.

Implementation sketch

• Flag wired in server/cmd/multica/cmd_daemon.go (alongside existing --agent-timeout, --max-concurrent-tasks, etc.).
• New field on daemon.Config propagated to the agent backend layer.
• In server/pkg/agent/claude.go, the existing conditional that appends --strict-mcp-config alongside --mcp-config stays; the path with no per-agent config gates on the new flag.
• Tests in server/pkg/agent/claude_test.go cover both modes.

Estimated size: ~50-100 lines + tests, no DB migration, no API change, no UI change.

Security posture

The trust boundary is preserved. The flag is opt-in by the daemon owner — the same person whose ~/.claude.json would be exposed to spawned agents. It's their machine, their MCPs, their decision. No cloud/managed runtime is affected (the flag would only have meaning on a daemon the operator controls). For multi-user shared runtimes the default-off behavior continues to apply.

Out of scope for this issue

• Per-agent UI/CLI for mcp_config — already covered by feat(agents): expose per-agent MCP / connector wiring in UI and CLI #2385.
• Workspace-level default MCPs — separate concern (cross-workspace, multi-user).
• Codex / OpenCode equivalent — these providers don't currently consume mcp_config (per [Bug]: Can't get MCP to work per agent #2106 triage); this issue scopes to Claude Code.

Happy to take this on

If a maintainer is not opposed to this direction, I'd be happy to prepare the PR.

Screenshots / mockups (optional)

No response

[zcking]

+1 would like to have this option in addition to per-agent mcp configs

[zcking]

What worked for me as a (dev only) local workaround was just commenting out the line from the claude agent:

./server/pkg/agent/claude_test.go
211://          "--strict-mcp-config",

./server/pkg/agent/claude.go
422://          "--strict-mcp-config"

then rebuild the daemon with make build and use the local binary to cycle the daemon if needed.

e.g.

multica daemon stop
brew uninstall multica # if you had the official CLI installed previously from homebrew
make build
cp server/bin/multica ~/.local/bin/multica
multica daemon start
multica daemon status

[j3k0]

FYI, I use custom agent wrappers to get around a few of those multica limitations, now including this one. https://github.com/j3k0/multica-local-workdir

(see LWD_ALLOW_MCP)

[kobeng]

@j3k0 I'd like to ask you something. Regarding other programming agents, such as codex-cli, which has various MCP services pre-configured, why don't the MCP configurations in codex-cli take effect when Multica calls the codex-cli commands? What causes this issue?

[nikolai-vysotskyi]

Opened #6062 proposing workspace-level MCP configuration, which I think gives this request a first-class answer rather than a workaround.

Inheriting from ~/.claude.json is really a proxy for "I want one shared MCP scope instead of N per-agent ones". A real shared scope is better on three counts: it's explicit rather than implicit, it's visible to the whole team instead of living in one machine's user account, and it doesn't silently pull in whatever the operator happens to have installed locally. It also doesn't require relaxing --strict-mcp-config.

Cited this thread as the demand signal — specifically @zcking commenting out --strict-mcp-config in claude.go:422 and rebuilding the daemon from source, and @j3k0's multica-local-workdir wrapper with its LWD_ALLOW_MCP flag. People patching the binary to get a feature is a stronger signal than the 9 reactions.

@kobeng — your question about Codex losing its pre-configured MCP servers has the same root: Multica passes its own config through the runtime's native channel and the runtime's own config isn't consulted. A workspace scope wouldn't change that mechanism, but it would mean you configure it once instead of per agent.

[Bohan-J]

This is fixed — and it turned out not to need an opt-in flag, because the behaviour you traced is now the default.

Your diagnosis was exactly right: the daemon passed --strict-mcp-config with no --mcp-config, which means "only use servers from --mcp-config" over an empty set, so the agent saw zero MCP servers.

Claude: fixed in #5277. --strict-mcp-config is now only passed when the agent actually has a Multica-managed mcp_config. With no managed config the flag is omitted entirely, so Claude Code inherits your ~/.claude.json servers exactly as it does in an interactive session — no flag to enable.

CodeBuddy: had the same bug until just now; fixed in #6556. It also gets the union you'd expect — a server configured in Multica is added to the ones already in your local CodeBuddy config rather than replacing them, and a Multica-side entry wins a same-name collision.

One thing worth knowing if you use per-agent mcp_config: when an agent does have managed servers, Claude runs in strict mode against a document the daemon merges from your runtime config plus the agent's own entries, so your local servers still come along. The design rationale from #1111 is preserved — spawned agents are still isolated from the outer session — but "no managed config" no longer means "no MCP at all".

Closing as resolved. If you're on a self-hosted daemon older than #5277, updating is what you need; happy to reopen if you still see zero servers after that.

[Bohan-J]

Follow-up for anyone still subscribed here: the shared MCP scope this thread kept circling — configure a server once for the team instead of per agent — shipped in #6062 and is live.

Short version: Workspace Settings → MCP is a library of MCP servers for the workspace; adding one there gives it to no agent, and an agent gets it when someone adds it on that agent's Capabilities → MCP tab, with a per-agent on/off toggle. From the CLI that is multica workspace mcp and multica agent mcp (v0.4.27).

This is separate from what this issue was closed for — inheriting your local ~/.claude.json servers works on its own, per the fixes in #5277 and #6556. The workspace library is for the case where the servers should belong to the team rather than to one machine's user account.