VS Code sandboxEnabled for MCP: does it cover a hosted Sume entry?

No. VS Code's sandboxEnabled setting applies to locally running stdio MCP servers on macOS and Linux, and Sume's hosted MCP server is a remote HTTP endpoint at https://mcp.sume.com/mcp. There is no local process to sandbox. The safeguards that matter for a Sume session are the ones the server enforces: OAuth scopes, idempotency_key, dry_run and an optional max_spend_usd.

The VS Code side is from its MCP server page, read on 2026-10-03; Sume's is from MCP tools and gates and OAuth and API keys.

What does the VS Code sandbox actually restrict?

The page says that on macOS and Linux you can sandbox locally running stdio servers, so they only reach the file paths and network domains you allow. You set "sandboxEnabled": true on the server in mcp.json and add a top-level sandbox object with filesystem rules such as allowWrite and network rules such as allowedDomains. It is not available on Windows.

One more line matters for approvals: when sandboxing is enabled, the server's tool calls are auto-approved because they run in a controlled environment. That trade is sensible for a local script that cannot leave its allowed paths. It would be the wrong trade for a remote server that can spend money, which is a reason not to expect the same behavior for a hosted entry.

What protects a paid Sume call instead?

Sume's docs say OAuth sessions see read-only tools unless Write is switched on at consent, there is no mcp:paid scope, and spend runs through wallet admission. Paid and write submits need an idempotency_key; dry_run preflights cost; max_spend_usd is enforced only when you provide it. API-key sessions see the full tool set, so the scope check is not a substitute for a spend cap there.

If you want a human in the loop on each paid call, that is a client setting, not a server one. VS Code can ask you to confirm each tool invocation, and its page notes you may be asked to confirm each call; leave that on for Sume's write tools.

What would a hosted entry look like with no sandbox keys?

Just the transport and URL. Adding sandboxEnabled to it would have nothing to restrict, and the page documents the key only in the context of a stdio server with a command.

Keep the file free of secrets. If you use an API key for automation, send it as Authorization: Bearer <key> or x-api-key from the environment and never commit it. Then run mcp_health once to see which auth source and safety posture the session has.

{
  "servers": {
    "sume": {
      "type": "http",
      "url": "https://mcp.sume.com/mcp"
    }
  }
}

Should I still review each paid call?

Yes. Sume's gates stop mistakes, not intent. An idempotency_key prevents a double submit, dry_run shows cost, and max_spend_usd caps a call when you set it, but none of them knows whether you wanted the render. Keep the client's per-call confirmation on for the write tools and turn it off only for read tools you use constantly.

Treat dry_run as the default first step for any new prompt. It is the closest hosted equivalent to what a sandbox gives a local script: a way to see the effect before it happens.