Trust before it runs

You’ve added the service-registry entry to .vscode/mcp.json, and VS Code has noticed it. Notice what didn’t happen: it didn’t connect. An MCP server is a program — possibly one you didn’t write — that’s about to reach into systems outside your editor on Copilot’s behalf. That’s exactly the kind of thing you want a deliberate yes in front of, not a silent default.

Confirm trust before the server starts

When you add a server, or change its configuration, Copilot asks you to confirm trust before it starts that server. Until you do, the entry sits in the file inert. This is the same instinct as the diff-review habit from your very first change: nothing reaches outside a boundary until a human keystroke says it can. Adding the config is describing a connection; trusting it is opening it.

If you ever want to revisit that decision — you’ve stopped using a server, or you want to re-evaluate one you trusted in a hurry — run “MCP: Reset Trust” from the Command Palette. It clears your trust decisions so the next start prompts you fresh. Cheap to reach for; reach for it whenever a server’s behavior surprises you.

Tool calls get confirmed too

Trusting the server to start is one gate. The calls it makes once it’s running are a second one. When Copilot wants to call a tool the registry exposes — say, “list the consumers of shared-lib” — that tool call needs your confirmation unless the tool is sandboxed. So even after you trust the registry server, the first time Copilot reaches for it mid-task, you get a say.

That’s the default, and it’s the safe one, because a tool call can have effects you didn’t anticipate. But confirming every read against a registry you trust gets old fast, and there’s a controlled way to lift it for servers where you’re sure.

The sandbox: a controlled exception

A server entry can declare a sandbox, which lets its tool calls run without per-call confirmation by constraining what they’re allowed to do. Two keys govern it (on macOS and Linux):

• sandboxEnabled — turns the sandbox on for that server.
• sandbox — the rules the sandbox enforces: which parts of the filesystem the server may touch, and what network access it may use.

The trade is explicit and worth understanding: you’re swapping per-call confirmation for up-front constraints. A registry server that only ever makes read-only queries to one internal host is a reasonable thing to sandbox — you box it into “read these paths, reach that host, nothing else,” and then let its calls run unprompted inside those walls. A server that can write or reach anywhere is one you’d think harder about before lifting the confirmation prompt.

One thing to keep straight

It’s tempting to file all of this under “Agent mode,” since that’s where you’ll watch Copilot call the registry mid-loop. Don’t. MCP isn’t agent-mode-only. The tools, resources, and prompts a server contributes are available across chat and agents — Ask can read a registry resource to answer a question, any mode can pull in a server-provided prompt. What Agent mode adds is autonomy: it executes those tool calls itself, in a loop, which is why the confirmation gates above matter most there. The trust model is general; it just bites hardest where Copilot is acting on its own.

You’ve got a trusted, optionally sandboxed server. But right now it’s wired at the workspace level — every conversation in this repo can reach it. For a high-blast-radius library, that’s broader than you want. Next: scope it to one agent.