Skip to content

feat(mcp): pre-approve the whole wick MCP server for spawned agents (mcp__wick)#606

Merged
yogasw merged 1 commit into
yogasw:masterfrom
aguung:feat/mcp-allowlist-wildcard
Jun 7, 2026
Merged

feat(mcp): pre-approve the whole wick MCP server for spawned agents (mcp__wick)#606
yogasw merged 1 commit into
yogasw:masterfrom
aguung:feat/mcp-allowlist-wildcard

Conversation

@aguung
Copy link
Copy Markdown
Collaborator

@aguung aguung commented Jun 7, 2026

What

Widens the spawned-agent MCP tool pre-approval from a static five-tool list to the server-level form --allowedTools mcp__wick, so every wick tool is auto-approved — the meta-tools plus the dynamic wick_manager_* surface (merged in v0.15.8) and wick_info / ask_user / wick_skill_* / wick_encrypt / wick_decrypt.

Why

wickMCPAllowedTools enumerated only wick_list/search/get/execute/list_providers. So the newer tools — especially the wick_manager_* management surface — were not pre-approved. On the gated spawn path (PermissionMode: on) they fell through to the command gate's "always ask" for MCP tools, which blocks in headless channels (Slack/HTTP, no human to answer) and prompts in interactive ones. That defeats the original purpose of the allowlist ("so the headless agent isn't blocked on a permission prompt nobody can answer").

The server-level mcp__wick form covers all wick tools dynamically, so future tools never need a static allowlist edit.

Not a security change

--allowedTools is a client-side prompt-skip, not the authorization boundary. wick enforces per-op access server-side — e.g. wickmanager's requireAdmin / requireTray / per-resource gates (used 37× in wickmanager/service.go; system_server_stop → requireAdmin). An unauthorized caller is rejected even though the tool is auto-approved client-side. And wick_execute — which can already run destructive connector ops — was always pre-approved, so this is consistent with the existing posture, not a new risk category.

Docs

  • docs/connectors/wickmanager.md — new "Command gate & management ops" section: why wick_manager_* skips the client gate, that server-side gates are the real boundary, and how to keep management ops controlled (tighten admin/tag access; system_* is tray-gated). Notes selective client-gate review as a possible future enhancement.
  • docs/guide/command-gate.md — tip that wick's own MCP tools are pre-approved (the "always ask" rule is for third-party servers).
  • docs/changelog.md[Unreleased] entry.

Testing

  • TestMCPConfigArgs updated to assert the server-level mcp__wick value (RED→GREEN).
  • internal/agents/provider/claude + internal/mcp suites pass (92 tests). go build ./cmd/lab ., gofmt clean.

The spawn allowlist (wickMCPAllowedTools) enumerated only five meta-tools,
so the new wick_manager_* tools (and wick_info, ask_user, wick_skill_*,
wick_encrypt/decrypt) were not pre-approved — on the gated spawn path they
hit the command gate's 'always ask' for MCP tools, which blocks in headless
channels and prompts in interactive ones.

Switch to the server-level form '--allowedTools mcp__wick', which covers
every wick tool (meta + the dynamic wick_manager_* surface) without a
static per-tool list. This is not a security change: --allowedTools is a
client-side prompt-skip, not the boundary — wick enforces per-op access
server-side (wickmanager's requireAdmin/requireTray/per-resource gates),
and wick_execute (which can already mutate) was always pre-approved.

Docs: note in connectors/wickmanager.md + command-gate.md that wick's own
tools skip the gate and are guarded server-side, and how to keep management
ops controlled (tighten admin/tag access; system_* is tray-gated).
@yogasw yogasw merged commit bf185ba into yogasw:master Jun 7, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants