Claude agents cannot access any MCP servers due to --strict-mcp-config without --mcp-config

[Korkyzer]

Summary

Multica-spawned Claude agents cannot access any MCP servers because the daemon launches claude with --strict-mcp-config but without an accompanying --mcp-config argument. This silently strips all user-scope MCPs (configured in ~/.claude.json or via claude mcp add) from the agent's tool inventory.

Reproduction

1. Configure any MCP server in your local Claude Code: claude mcp add some-server --scope user -- npx some-mcp
2. Verify it loads in a normal Claude Code session: claude mcp list shows it as connected
3. Create a Multica issue and assign it to a Claude agent (any model)
4. In the issue brief, ask the agent to call a tool from some-server or to list its available MCPs
5. Observed: the agent reports the MCP tool is unavailable; claude mcp list from the agent's bash shows the MCPs as configured but they are not loaded into the running session

Root Cause

The daemon spawns the Claude provider via buildClaudeArgs in server/pkg/agent/claude.go (line 356-371):

func buildClaudeArgs(opts ExecOptions, logger *slog.Logger) []string {
    args := []string{
        "-p",
        "--output-format", "stream-json",
        "--input-format", "stream-json",
        "--verbose",
        "--strict-mcp-config",          // line 362
        "--permission-mode", "bypassPermissions",
    }
    // ...
}

Per the Claude CLI documentation:

--strict-mcp-config -- Only use MCP servers from --mcp-config, ignoring all other MCP configurations

Since no --mcp-config argument is ever passed (and ExecOptions in server/pkg/agent/agent.go:22-30 has no field for it), the result is: zero MCPs loaded. The agent only has access to native Claude Code built-in tools (Bash, Read, Write, WebSearch, etc.) and binaries on PATH.

Impact

• All user-configured MCPs in ~/.claude.json are invisible to Multica Claude agents
• The Multica MCP server itself cannot be used by Multica agents -- agents cannot create child issues, post comments, or interact with the platform from inside a task via MCP
• Any workflow depending on MCP tools (Figma, GitHub, database access, etc.) is impossible at the agent level
• This affects every Claude-provider agent in every Multica deployment

This issue is distinct from #674 (Codex MCP tools) -- the root cause here is specific to how the Claude provider is spawned and the semantics of --strict-mcp-config.

Related upstream issues

This pattern of MCPs not propagating to spawned subprocesses is a known friction point in the Claude Code ecosystem:

• Feature Request: Allow subagents (Agent tool) to access MCP server tools anthropics/claude-code#34935 -- subagents cannot access MCP server tools
• [BUG] Custom plugin subagents cannot access MCP tools (built-in agents can) anthropics/claude-code#13605 -- custom plugin subagents cannot access MCP tools

Multica is well-positioned to address this at its own layer rather than wait for upstream changes.

Proposed Solutions

Three options in order of preference:

Option A: per-agent mcp_config field (recommended)

Add an optional McpConfig field to ExecOptions. The daemon serializes it to a temp JSON file at spawn time and passes it via --mcp-config <path>:

// In server/pkg/agent/agent.go
type ExecOptions struct {
    Cwd             string
    Model           string
    SystemPrompt    string
    MaxTurns        int
    Timeout         time.Duration
    ResumeSessionID string
    CustomArgs      []string
    McpConfig       *MCPConfig // optional: if set, written to temp file and passed via --mcp-config
}

Example agent definition (YAML/TOML side):

name: claude-sonnet-figma
provider: claude
model_hint: sonnet
mcp_config:
  mcpServers:
    figma:
      type: stdio
      command: npx
      args: ["-y", "@figma/mcp-server"]
      env:
        FIGMA_ACCESS_TOKEN: "${FIGMA_ACCESS_TOKEN}"

Pros: granular per-agent control, secure (no automatic inheritance of sensitive MCPs), backward compatible (optional field).
Cons: users must declare MCPs explicitly; no automatic inheritance from ~/.claude.json.

Option B: optional --strict-mcp-config flag

Add a daemon-level config or per-agent flag to omit --strict-mcp-config, letting Claude inherit user-scope MCPs from ~/.claude.json automatically.

Pros: zero config burden for users who want all their MCPs available.
Cons: less secure (every agent sees every MCP including potentially sensitive ones).

Option C: workspace-level MCP config

Allow defining a default mcp_config at the workspace or runtime level, applied to all agents on that runtime.

Pros: middle ground, less repetition than Option A.
Cons: less granular.

Environment

• Multica 0.2.0 (commit: df920e8, built: 2026-04-15)
• Claude Code 2.1.110
• macOS 26.2 (darwin/arm64)

Willingness to Contribute

Happy to help draft a PR for Option A if the maintainers consider this worthwhile. Would appreciate guidance on:

• Where the agent definition schema is declared (for adding the mcp_config field on the config side)
• Preferred temp file lifecycle (create on spawn, delete on exit?)
• How McpConfig should interact with existing CustomArgs (e.g., if a user passes --mcp-config via custom_args, should it take precedence?)

[Bohan-J]

Hey @Korkyzer — thanks for the unusually thorough report. You diagnosed this correctly: --strict-mcp-config without --mcp-config zeroes out MCPs by design, and there is no field in ExecOptions to carry one. We're green-lighting Option A (per-agent mcp_config) and would happily review a PR from you. Some context + answers to your open questions below.

Why --strict-mcp-config was added in the first place

Short version: it was added defensively alongside env filtering in #592 ("Fix Claude stream-json startup hangs"), not as a deliberate "MCPs off" product decision.

That PR's main goal was fixing a startup hang. Bundled with it:

• Filter inherited CLAUDECODE / CLAUDE_CODE_* env vars before spawning the child Claude.
• Add --strict-mcp-config.

The motivation for both was the same: the Multica daemon is often launched from a developer's own Claude Code terminal, and we didn't want the outer Claude Code session's state — env vars or MCP inheritance from ~/.claude.json — leaking into every spawned agent. One-line way to cut the MCP inheritance: --strict-mcp-config.

What was missed: we never added the --mcp-config <path> counterpart, so the intended "daemon controls what MCPs children see" design shipped as "children see zero MCPs." So your fix is completing the original design, not reversing it. The flag should stay; we just need the structured injection path next to it.

Answers to your open questions

1. Where is the agent definition schema?

There isn't a YAML/TOML agent definition file — agents are DB-backed. The schema lives in two places:

• DB model: db.Agent (sqlc-generated from server/pkg/db/queries/ + migrations in server/migrations/). The relevant sibling fields today are custom_env (JSON map) and custom_args (JSON array).
• HTTP surface: server/internal/handler/agent.go:16-38 (AgentResponse) and the create/update request structs further down that file.

Natural place for McpConfig is a new nullable JSON column on the agents table, right alongside CustomEnv / CustomArgs. That means:

1. A new migration adding a mcp_config jsonb column.
2. make sqlc to regenerate.
3. Plumb it through AgentResponse + create/update request structs.
4. Pipe it into ExecOptions.McpConfig in server/internal/daemon/daemon.go:1055 (where CustomArgs is wired today).
5. In buildClaudeArgs, serialize to temp file and append --mcp-config <path>.

Bonus: same shape means the Multica web UI can eventually let users edit it per-agent like they already edit custom_env / custom_args.

2. Interaction with CustomArgs

Add --mcp-config to claudeBlockedArgs (see claude.go:349) as blockedWithValue. Structured ExecOptions.McpConfig becomes the only way to set it. Reasons:

• Keeps one source of truth — avoids the footgun of a user pasting a stale path into custom_args and silently overriding their structured config.
• Matches the precedent set by --permission-mode and --output-format, which are already in the blocklist.

3. Multica MCP auto-injection

Out of scope for this PR — please don't bundle it. We want to land the plumbing first, then decide the "daemon merges its own MCPs into the final config" policy in a follow-up (likely opt-in at runtime level, since cloud runtimes and local daemon have different needs). For this PR, McpConfig being nil → no --mcp-config argument → current behavior preserved; McpConfig set → exactly those servers get loaded.

4. Temp file lifecycle

os.CreateTemp at spawn time; register cleanup with a defer os.Remove(path) inside the goroutine that already owns cancel() / cmd.Wait() in claudeBackend.Execute. The session lifetime is bounded by that goroutine, so no separate hook needed.

5. Codex (#674) alignment

Please keep scopes separate. Ship Claude first in this PR; we'll rebase Codex on the same ExecOptions.McpConfig field afterwards, since Codex's config format is different enough (TOML-based, different MCP semantics) that unifying prematurely will slow things down. The ExecOptions.McpConfig type you add here should be shaped to be provider-agnostic where possible, but we don't expect you to wire up Codex.

Scope suggestion for the PR

• Migration + sqlc + handler wiring for the new mcp_config column.
• ExecOptions.McpConfig field + temp-file serialization + --mcp-config emission in buildClaudeArgs.
• --mcp-config added to claudeBlockedArgs.
• Tests in claude_test.go covering: (a) nil config → no --mcp-config arg; (b) non-nil config → flag present, temp file matches expected JSON; (c) custom_args containing --mcp-config is filtered with a warning log.
• No Multica MCP auto-injection, no Codex changes, no UI surface — those are follow-ups we'll own.

Also — we'll be linking #1040 to this issue as a likely duplicate user complaint of the same root cause.

Happy to review promptly once you open the PR. Ping me if the migration + sqlc loop is unfamiliar and I can point at a recent PR as a template.

[pmancnsh]

Agent tool can't work if THE mcp server needs a OAuth Client ID, even claude code was alreay authorized with a proper token.