VS Code user MCP config: a read-only and a Write Sume profile
VS Code's MCP: Open User Configuration edits per-user servers. Keep OAuth read-only Sume in your everyday setup and an API key entry only where paid jobs run.
Put one Sume entry in your VS Code user configuration with OAuth and no Write, and add a second, key-based entry only in the place where paid generation should happen. The VS Code page lists the command MCP: Open User Configuration for per-user servers, alongside workspace files. A user-level entry follows you into every workspace, so it should be the least powerful credential you are willing to carry everywhere.
Where each kind of entry belongs
The VS Code page describes workspace trust and separate trust prompts for servers outside the workspace, so a server in your user configuration still asks before it starts.
| Location | Scope of effect | Sume credential to use |
|---|---|---|
| .vscode/mcp.json (servers) | One workspace; usually committed | None, or an input variable prompt; no literal key |
| .mcp.json (mcpServers) | One workspace; portable format | None; never a literal key |
| MCP: Open User Configuration | Your user, every workspace | OAuth with Write off |
| ~/.copilot/mcp-config.json | User-level portable file | OAuth with Write off, or a key via an environment reference |
Why split by place
Under OAuth with only mcp:read, Sume hides its write tools, so an everyday assistant can list models, read balances and check jobs without any way to start paid work. A key entry exposes the full tool set, including paid generation, so it belongs where you have decided to spend.
Because a workspace file is often committed, never put a literal key in it. A teammate who clones the repository gets the entry and the prompt, not your credential, and signs in with their own.
Verifying each setup
Write and paid calls need an idempotency_key under either credential, and max_spend_usd bounds a call only when it is sent. The split above reduces who can reach those tools; it does not cap how much a permitted call can spend.
- Open the tool list in each setup and compare it with the other.
- Call mcp_health to see which credential is live.
- Try a write tool under the read-only setup and expect insufficient_scope with required_scope mcp:write.
Keeping it tidy
Name the entries so the difference is obvious in the tool picker, for example sume-read and sume-write, and disable the write entry when you are not using it. Rotate the key from the dashboard if you suspect it has been copied, and remember that an OAuth access token expires after an hour with no refresh, so the read-only entry will ask you to sign in again from time to time.
Sources
Related posts
More in Integrations
- VS Code 1.141 background shells and a long Sume render
VS Code 1.141 tracks background shells for agent sessions. Start a Sume render, keep the job id, and use sume jobs watch instead of repeating the paid create.
- Azure Logic Apps HTTP action times out at 120 s: long Sume runs
Logic Apps HTTP actions time out at 120 s. Start a Sume Format run (202 receipt), pass a webhook URL, and set an idempotency key so retries stay safe.
- Bitbucket merged-PR webhook to a Sume Format run: verify first
Verify Bitbucket's X-Hub-Signature (sha256=) with its published test values, then start a Sume Format run on pullrequest merged with a key built from the PR.
- Buildkite webhook: X-Buildkite-Token or Signature before a Sume run
Buildkite pipeline webhooks offer a clear-text token or an HMAC-SHA256 signature. Use the signature on build.finished before you start a paid Sume Format run.
Written by Sume