Custom agent's mcp.enabled: false override doesn't disable the runtime MCP proxy

[jhrozek]

Summary

Found during review of #210. A custom (bring-your-own) agent can set mcp.enabled: false in its config override, and this is correctly reflected in bbox agents inspect and the agents add/doctor JSON receipt (both compute mcpDisabled from override.MCP.Enabled). However, the actual runtime MCP proxy wiring in cmd/bbox/main.go's applyCustomAgentAuthzDefault path is only reached inside the block gated by the global MCP toggle (--no-mcp / cfg.MCP.Enabled) — it never consults the per-agent override.MCP.Enabled field.

Net effect: a custom agent that declares mcp.enabled: false for itself does not actually get the MCP proxy disabled at VM start time when MCP is globally enabled. The CLI's own display/diagnostic surfaces (inspect, doctor receipt) show the agent as MCP-disabled, but the runtime behavior disagrees.

Where to look

• cmd/bbox/main.go — the MCP proxy setup path (applyCustomAgentAuthzDefault and its caller, gated by the global mcpEnabled check), around main.go:850-900ish (line numbers as of PR Add bbox agents add/init scaffolding (#201) #210; verify current location).
• cmd/bbox/agents.go — renderInspect, which correctly computes mcpDisabled from override.MCP.Enabled for display purposes.
• cmd/bbox/agents_receipt.go — buildReceiptAgent, same per-agent mcpDisabled computation for the JSON receipt.
• pkg/domain/config — the per-agent MCP override resolution (ResolveMCPConfig or similar) may already have the right logic for the display path; the gap is that the runtime wiring in main.go doesn't call the same resolution before deciding whether to start the proxy for a given agent.

Suggested fix direction

Ensure the runtime MCP proxy setup consults the same effective per-agent mcp.enabled resolution that inspect/doctor already use, so a custom agent declaring mcp.enabled: false actually skips proxy wiring for that agent's VM, not just its displayed status.

Context

Surfaced by a go-architect review agent while scoping a refactor to deduplicate custom-agent default-resolution logic (MCP authz profile / egress profile) across cmd/bbox/main.go, cmd/bbox/agents.go, and cmd/bbox/agents_receipt.go. That refactor itself was deferred as lower priority; this bug is separate and was split out to track independently.

[jhrozek]

Correction after deeper investigation while reviewing PR #212: this is not actually a bug.

I traced the runtime path more carefully:

• `pkg/sandbox/sandbox.go`'s `resolveMCPConfig` (around line 1023-1038) reads the per-agent `override.MCP.Enabled` and correctly copies it into the effective `mcpCfg.Enabled` used for that agent's VM.
• `MCPConfig.IsEnabled()` (`pkg/domain/config/config.go:563`) respects that value (defaults to true only when nil).
• The actual gate that decides whether a VM gets wired to the proxy — `sandbox.go:533`, `if mcpCfg.IsEnabled() && s.mcpProvider != nil` — controls whether `HostServices`/`BBOX_MCP_URL` are populated for that specific agent's VM.

So a custom agent declaring `mcp.enabled: false` genuinely does get the proxy disabled for its own VM: no `BBOX_MCP_URL`, no host service wiring, nothing to connect to.

What I originally flagged (`applyCustomAgentAuthzDefault` in `cmd/bbox/main.go` only being reached inside the global MCP-enabled block, never consulting the per-agent override) is true as a code-level observation, but it only affects which authz profile gets computed for the host-level proxy singleton — and an agent that's disabled at the per-agent level never connects to that singleton anyway per the gating above, so there's no observable effect.

Closing as not-a-bug. Apologies for the noise.