VS Code 1.140 session authorization server: what Sume issues
VS Code 1.140 proposes a field naming the authorization server behind a session. For Sume, that server is the MCP origin, mcp.sume.com.
For a Sume session over MCP in VS Code, the authorization server that issued it is the MCP origin, https://mcp.sume.com. It is not www.sume.com or app.sume.com. The VS Code 1.140 update describes a proposed API field that reports this per session.
The VS Code text is from its updates page; the Sume side is from MCP OAuth and API keys. Both were read 2026-10-01.
What does the VS Code 1.140 update add?
Under Proposed APIs, the page says the authIssuers proposal already lets an extension name the OAuth authorization server it wants to authenticate against, which VS Code introduced for MCP in 1.101. This release adds the opposite direction: an AuthenticationSession can say which authorization server issued it, "when provided by the authentication provider". The doc comment adds that this identifies the OAuth server, not a REST API endpoint or resource audience.
It is a proposed API, so it is not something to depend on in a shipped extension.
Which server issues a Sume session?
Sume's docs state it directly. Protected-resource metadata lists authorization_servers as the MCP origin, the client is sent to https://mcp.sume.com/oauth/authorize, and consent runs on the MCP host. www.sume.com remains a secondary and deprecated authorization-server surface that the metadata no longer advertises.
| Role | Value in the docs |
|---|---|
| Authorization server | The MCP origin, https://mcp.sume.com |
| Metadata | https://mcp.sume.com/.well-known/oauth-authorization-server |
| Authorize | https://mcp.sume.com/oauth/authorize |
| Resource audience | https://mcp.sume.com/mcp |
Why do the issuer and the audience differ?
The authorization server answers who issued the session; the resource audience answers which server the token is for. For Sume these are different values on the same host, which matches the VS Code comment that the new field is not a resource audience. More on that split in MCP OAuth token audience.
What should I check in an extension?
If your code compares an issuer to an expected value for Sume, compare against the MCP origin and fetch the metadata from the .well-known URL above rather than hard-coding a different host. Treat a missing issuer as unknown, since the field is only present when the provider supplies it.
Sources
Related posts
More in Integrations
- Zapier action timeout at 30 seconds: use Sume webhook mode
Zapier actions time out at 30 seconds, so submit Sume jobs with mode webhook: the call returns a job id at once and Sume posts the result to your URL later.
- Zapier Catch Hook 404 when the Zap is off: Sume webhook retries
A turned-off Zap now returns 404 to Catch Hook. For a Sume job that is a failed delivery attempt: it retries up to 10 times, then redeliver or poll recovers.
- Zapier Functions shut down Sept 1: move media calls to Sume async
Zapier Functions stopped running on 2026-09-01. Move a media-API step to Code by Zapier and submit a Sume job async or by webhook instead of waiting on it.
- Zed 1.22 subagent compaction: keep Sume job ids out of the summary
Zed 1.22.0 compacts subagent threads automatically and lets spawn_agent pick a model. Hand Sume job ids over explicitly so a summary cannot lose them.
Written by Sume