revert: "fix(mcp): agent mcp_config is an authoritative allowlist" (#6292) (MUL-5655)

[multica-eve]

Reverts #6292 (aa349fed02f215421df5dbca9cd9752421e3b7ac).

Requested by Yushen on the 2026-08-03 release confirmation issue MUL-5655, after Preflight returned BLOCK on today's v0.4.17 window.

Why

#6292 made an agent's mcp_config an authoritative allowlist and enforced it in the daemon. To stay safe across mixed versions it added a claim-time gate: a managed, non-inheriting mcp_config claimed by a daemon that does not advertise the authoritative-mcp-v1 capability fails the task with mcp_config_daemon_outdated and returns 412 on the per-runtime path.

That gate is the blocker. If the server ships before local daemons upgrade — or during any rolling window — the next task of every existing strict-MCP agent on claude, codebuddy, codex, cursor, opencode, or openclaw fails outright instead of waiting for a newer daemon, and the failure is not auto-retryable. We do not currently have production daemon capability coverage or a count of affected agents, so the mixed-version window cannot be ruled out.

Reverting unblocks the release. The underlying defect (#6283 — an empty MCP config exposing all of the host's MCP servers) returns with the revert and needs to be re-landed once daemon rollout is confirmed.

What this restores

• mergeRuntimeAndAgentMcpConfig additive behaviour — a non-null mcp_config is merged with the runtime host's MCP servers again.
• Removes resolveEffectiveMcpConfig, runtime_config.mcp.inherit_runtime, mcp_config_overlay_only, the authoritative-mcp-v1 daemon capability, and the mcp_config_daemon_outdated failure reason, along with their tests and locale strings.
• builtin_skills/multica-creating-agents loses the mcp_config allowlist section added by MUL-5637 fix(mcp): agent mcp_config is an authoritative allowlist #6292. The unbound-agent content from feat(runtime): unbind agents on runtime delete instead of destroying them #6220 is untouched and still present — verified.

Scope check

git revert applied with no conflicts; 57 files, exactly the inverse of aa349fed0. No file overlap with #6291, the only commit merged after it. grep for every symbol #6292 introduced returns no residual references outside apps/docs.

Verification

Backend:

• gofmt -l on all changed Go files — clean
• go build ./... — clean
• go vet ./internal/daemon/... ./internal/handler/... ./pkg/taskfailure/... ./internal/metrics/... ./cmd/multica — clean
• go test ./internal/daemon/... ./pkg/taskfailure/... ./internal/metrics/... — all pass (this is where the reverted logic lived)
• go test ./internal/handler/... fails in my sandbox, but identically on clean main: the shared dev Postgres is behind migration 224 (ERROR: column "session_rollout_missing" does not exist). Same tests, same messages on both refs. I did not migrate that shared DB. CI's DB-backed backend suite is the authority here.

Frontend:

• pnpm --filter @multica/core run typecheck and pnpm --filter @multica/views run typecheck — clean
• pnpm --filter @multica/views exec vitest run agents/ chat/ — 50 files, 395 tests, all pass
• pnpm --filter @multica/core exec vitest run — 1178 pass, 8 fail in projects/mutations.test.tsx, realtime/use-realtime-sync-ws-instance.test.tsx, workspace/mutations.test.tsx. All three files fail the same way on clean main and none are touched by this revert.

Follow-up

• Changelog PR docs(changelog): add v0.4.17 release entry (2026-08-03) (MUL-5655) #6311 claims this fix in the 0.4.17 entry; that line is being removed there.
• [Bug]: agent mcp_config is silently ignored on the claude runtime — every host MCP server stays reachable #6283 is open again. Re-landing needs a daemon-first rollout plan, production authoritative-mcp-v1 coverage, and an inventory of agents with a non-null object mcp_config.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
multica-docs	Ready	Preview	Aug 3, 2026 9:41am