Copilot CLI 1.0.95 and 1.0.96 sandbox secrets: where Sume's key fits

The two newest stable Copilot CLI releases touch sandbox credentials: 1.0.95 says "copilot config supports sandbox credential injectHosts keys", and 1.0.96 says "Interactive sandbox settings suggest possible environment secrets and let you add masking hosts before saving." For Sume's hosted MCP server, the simplest way to keep a secret out of the picture is OAuth; the API key path works too, as a header on https://mcp.sume.com/mcp.

This post does not describe how injectHosts behaves internally. The release notes give only the key name, so read GitHub's Copilot CLI docs before you rely on it.

What do the 1.0.95 and 1.0.96 notes say?

Both are short. The facts are in the table below; everything else about sandbox semantics lives in GitHub's documentation, not in the release notes.

Does Sume's MCP need a secret in the sandbox at all?

The OAuth page lists two ways in. OAuth is preferred for interactive clients: you sign in and choose Read, or Read and Write, at consent. The quickstart for Claude Code shows claude mcp login sume for this, and Cursor needs only the URL in its config.

The other way is an API key sent as Authorization: Bearer <SUME_API_KEY> or as x-api-key. Send one of these, not both. Whatever holds that key is something you may want a sandbox to mask.

Which should I pick for a sandboxed terminal agent?

Pick by whether a person is present. If someone can complete a browser sign-in, OAuth keeps the key out of your environment and lets you leave Write off for read-only work. If the run is headless, the key is the practical choice, and because it equals full write access, the safety gates matter more.

• Interactive: OAuth, Read only unless the task renders.
• Headless: API key in an environment variable, never in the URL or a committed file.
• Either way: send idempotency_key on writes, plus dry_run=true or max_spend_credits where you want a pre-check or a cap.

What should be masked or allowed?

Treat the key value as the secret and mcp.sume.com as the host you expect to reach. If your sandbox also blocks outbound network by default, the host needs to be reachable for the MCP connection to work. Test with mcp_health, which reports readiness and auth state without spending anything.

What is the least risky setup to test first?

Start with a read-only OAuth sign-in. It needs no secret in the environment, the sandbox has nothing to mask, and the agent can still list models and read your balance and jobs. Once that works, repeat with Write enabled and a single dry_run=true generation to confirm the estimate comes back as credits without a job being created.

Only then consider the API key path for headless use. Put the key in an environment variable that the sandbox settings dialog can suggest and mask, and keep it out of any URL. The docs say to avoid pasting signed URLs, tokens or API keys into logs, and to report with public Sume IDs and media.sume.com URLs instead.

The /add-dir change in 1.0.96 is about file access, not network access. It does not affect whether the MCP connection works, so do not use it to troubleshoot a connection problem.