feat(config): layered config tool filter — config_denied over user toggles

[nlaurance]

Summary

• Replaces the BBolt-mutating applyConfigToolFilter (which overwrote user-owned Disabled flags on every reconnect) with a pure evaluation-time config layer
• enabled_tools / disabled_tools in mcp_config.json are now enforced without touching user preferences, emitting spurious audit events, or silently re-enabling tools the user manually disabled

What changed

Backend

• ServerConfig.IsToolAllowedByConfig(toolName) — pure config helper
• Runtime.IsToolConfigDenied(serverName, toolName) — evaluation-time check, no BBolt writes
• isToolCallable (MCP enforcement chokepoint) checks config layer before BBolt record.Disabled — config-denied tools are hard off across all paths (call_tool_*, retrieve_tools, upstream_servers tool counts)
• SetAllToolsEnabled skips config-denied tools so bulk Enable All never sets a misleading Disabled=false on a hard-off tool
• GET /api/v1/servers/{id}/tools exposes config_denied: true per tool
• POST /api/v1/servers/{id}/tools/{tool}/enabled returns HTTP 409 when trying to enable a config-denied tool
• UpstreamRecord now persists EnabledTools / DisabledTools through BBolt round-trips (bug fix)

Frontend

• Tools with config_denied: true show a locked by config badge and a read-only label instead of a toggle
• Quarantine panel hides the Approve button for config-denied pending/changed tools (shows a lock badge instead)
• Tool interface in api.ts now properly types disabled, config_denied, approval_status, etc.

Effective visibility model

callable = configAllows(tool) AND userEnabled(tool)

Config can only restrict further — it can never force a tool back on against the user.

Test Plan

• Unit tests: go test ./internal/config/... ./internal/runtime/... ./internal/server/... ./internal/httpapi/... ./internal/storage/... — all pass
• Frontend: cd frontend && npm run build — clean build
• Config with enabled_tools: ["list_issues"] → create_issue unreachable via MCP, shows locked in UI
• Config with disabled_tools: ["delete_repo"] → delete_repo unreachable, locked in UI
• User disabling a tool in the UI survives server reconnect (no longer reset by config)
• POST /api/v1/servers/{id}/tools/delete_repo/enabled with {"enabled": true} → 409 Conflict
• Pending/changed quarantine tool that is also config-denied shows lock badge, not Approve button

🤖 Generated with Claude Code

[Dumbris]

Thanks @nlaurance — clean implementation and genuinely thorough tests. I support the idea of config-based tool filtering — declaring tool visibility in mcp_config.json is the right capability for fresh installs and gitops setups, and the allowlist's fail-closed posture against tool-surface growth is exactly in our threat model.

My concern is purely the interaction model with the per-tool enable/disable that recently landed (#463 Web UI, #447, REST/CLI SetToolEnabled). applyConfigToolFilter writes config intent into the same ToolApprovalRecord.Disabled BBolt flag those paths own, on every applyDifferentialToolUpdate (i.e. every reconnect). Concretely this means:

• There's no durable provenance — ToolApprovalRecord has no source field, so after the first write a config-disabled tool is indistinguishable from a user-disabled one. updatedBy="config" is dropped.
• A tool the user manually disabled in the UI that's in enabled_tools gets silently re-enabled on every reconnect — TestApplyConfigToolFilter_EnabledTools_ReEnablesTool pins this as intended, but that's the behavior I'd push back on.
• It emits a tool_disabled activity event on every reconnect, polluting the audit trail.
• A config-denied tool keeps its pending/changed quarantine status, so upstream inspect/approve still invites the user to approve a tool config will keep hidden.

Definition I'd like us to agree on

For me, config-based filtering should mean hard-off for unwanted tools, and for that to be solid it has to be transparent, predictable, and surfaced in the UI and CLI — never a silent toggle that snaps back. Precisely:

• Effective visibility = configAllows(tool) AND userEnabled(tool). Config can only restrict further; it can never force a tool back on against the user.
• A tool denied by config (in disabled_tools, or absent from a non-empty enabled_tools allowlist) is HARD OFF.
• Config-denied tools are shown in the Web UI and CLI as locked + badged ("disabled by mcp_config.json") — toggle is read-only, and the server rejects an override attempt from a stale client.
• A config-denied tool that is also pending/changed in quarantine shows the config lock, not an "approve me" affordance.
• Config-allowed tools remain normally user-toggleable.

Spec use cases

1. disabled_tools: ["delete_repo"] → delete_repo HARD OFF, UI shows it locked+badged, upstream inspect shows SOURCE=config. User cannot enable it.
2. enabled_tools: ["list_issues"], server also exposes create_issue → create_issue is HARD OFF (implicit deny), locked+badged. list_issues is a normal toggle the user may still disable.
3. User disables list_issues (in enabled_tools) via the UI → it stays disabled across reconnects; config does not re-enable it.
4. Operator has an allowlist set and the upstream server adds new tools → new tools are denied by default, no manual action needed.
5. A pending tool that's also config-denied → shown as config-locked, not surfaced for approval.

Implementation-wise this means config should override the stored DB enable state at evaluation time rather than overwriting it: evaluate the config layer in isToolCallable (the single chokepoint that already covers all enforcement paths + code_execution), keep record.Disabled exclusively user-owned, expose a derived config_managed field on the tools API so the UI/CLI can lock+badge, and stop emitting per-reconnect audit events.

Does this definition work for you? If we're aligned on it, I'm happy to pair on this PR and convert the current behavior to override the DB option after config read along these lines — the config fields + mutual-exclusion validation you've already written are solid and stay as-is.

[nlaurance]

now rebased with changes suggested

[Dumbris]

LGTM. Layered config tool filter is the right design (config restricts, never force-on; user prefs preserved across reconnect). Added the 4 UX-review fixes in 7aa683b: status-aware TOOL_BLOCKED message (config-policy vs user-disable), neutral lock badges, Enable-All skip feedback, copy consistency. All CI green; local config/runtime/storage/httpapi + server blocked-tool unit tests pass. Follow-up (agent-discoverable disabled tools) tracked as spec 049.