Proposed API access

Check V8 · execution family · automatic · one of the 17 VS Code Marketplace checks

The question this check asks: which of VS Code's proposed — unfinished, not yet stable — APIs does this extension declare it wants, and does the VS Code you run actually grant them to it?

Why it matters

VS Code exposes two API surfaces. The stable one, every extension gets. The proposed one — APIs still being designed — is opt-in twice over. An extension names each proposal it wants in the manifest's enabledApiProposals (the gallery mirrors the list as Microsoft.VisualStudio.Code.EnabledApiProposals), and a stable build honours that declaration only for extensions on an allowlist compiled into the build's own product.json, under extensionEnabledApiProposals. That allowlist is distro-only. The product.json in the public VS Code repository carries none of it; you read it from an installed build. In VS Code 1.138 it names 65 extensions from 22 publishers — Microsoft's own ids (ms-python, ms-vscode, ms-vscode-remote, ms-vsliveshare, ms-azuretools, ms-dotnettools, ms-toolsai), GitHub, and a short tail that includes openai and vscjava. ms-python's Python extension declares nine proposals and is on it.

So for an extension not on that list, a stable VS Code ignores the declaration — and V8 scores it anyway, for two reasons. A fork or an Insiders build may not ignore it; the allowlist is a property of the build, and the build a developer runs is not always the one that would refuse. And the declaration is a statement of intent. Eleven proposals read the terminal or the user's sign-in state — the credential- exfiltration surface on its face: terminalDataWriteEvent, terminalExecuteCommandEvent, terminalSelection, terminalShellEnv, taskExecutionTerminal, authenticationChallenges, authLearnMore, authGetSessions, authSession, authIssuers and authProviderSpecific. An extension nobody has granted these to, asking for them, is worth knowing about before it is installed, whatever the build does with the request.

V8 sits in three of the four dimensions RepoGates derives from the 17 checks: open in an editor, install and run and hand to an AI agent. It is the natural second question after V7 has said the extension executes: what does the code reach for beyond the API every extension has?

How RepoGates scores it

V8 collects the declared proposals from the gallery property and the manifest, then looks the extension's id up in the allowlist. On the list, it emits one vsx-api-proposal row at INFO — a note naming what is declared and that VS Code honours it for this extension. Off the list, it emits one row per proposal, vsx-api-proposal:<name>: MEDIUM, 5 points for an ordinary proposal, HIGH, 12 points for one of the eleven in the sensitive set. The rows are capped at five, worst first — the sensitive proposals sort ahead of the rest, so a MEDIUM never displaces a HIGH from the cap. The scoring table's evidence note, verbatim:

"V8; proposed API declared by an extension not on VS Code's allowlist — HIGH for terminal/auth readers; a note when VS Code honours it for this extension"

The verdict engine behind all 17 checks: any CRITICAL finding is BLOCK; any HIGH or MEDIUM is REVIEW; INFO only is PASS. The score is separate — 100 minus every fired penalty, floored at zero; 80 and above green, 50 to 79 amber, under 50 red. One ordinary proposal on an extension off the list is a REVIEW at 95; one sensitive proposal is a REVIEW at 88; five sensitive proposals, the most the cap will show, cost 60 points for a score of 40 — red — and the verdict is still REVIEW, because no proposal is a CRITICAL. V8 on its own never moves an extension to BLOCK; the preflight and the MCP tools see the profile's warn action and put the question to the person installing.

False positives we know about

In the 18 September 2026 measurement of the 100 most-installed extensions, 16 declared proposals, and all 16 are on the allowlist — sixteen notes, zero points, no MEDIUM or HIGH from this check. The run came out 99 PASS, 1 REVIEW, 0 BLOCK. Two shapes would produce a false positive. An extension that VS Code adds to the allowlist in a release newer than 1.138 is graded as not allowlisted until RepoGates' weekly refresh of the reference file catches up — a REVIEW for the interval. And an extension that declares a proposal it only exercises on Insiders — ordinary practice for a maintainer developing against an unfinished API — is graded on the declaration regardless. In both cases the cost is the warn action on a REVIEW, and the finding names the exact proposal.

What this check does not cover

V8 reads a declaration. It does not read the bundle, so what the code does with a proposal it is granted — or with the stable API — is out of view. The stable API is enough for most harm: Koi Security's MaliciousCorgi pair (January 2026, as quoted by BleepingComputer and The Hacker News) read every opened file and posted it to a server, and reading an open document needs nothing beyond the API every extension already has. No listing check reads that code; the metadata tier would not have flagged MaliciousCorgi, and a deep scan of the bundle is the tool for it. The allowlist itself is a snapshot of one VS Code version, 1.138, and not the build on the developer's machine; a fork such as Cursor or Windsurf carries its own. RepoGates assesses a Marketplace extension on request — through the API, the MCP server (platform="vsx") and the preflight for code --install-extension. It does not see an extension installed from the editor's own UI, or one that auto-updates; the board on marketplace pages is not built yet; Open VSX (where VSCodium, Cursor and Windsurf install from) is a different registry and is not assessed. The extension's code bundle is not read on this tier: a PASS means the provenance and the declared surface are clean, never that the JavaScript was inspected.

Check it yourself

Open the extension's package.json — the gallery serves it as the Microsoft.VisualStudio.Code.Manifest asset — and read enabledApiProposals. Then open the product.json inside the VS Code build you actually run, not the one on GitHub, and look for the extension's id under extensionEnabledApiProposals. If the id is absent, that build ignores the declaration. For any name you do not recognise, the VS Code repository documents each proposal in a file called vscode.proposed.<name>.d.ts — the ones that begin terminal or auth are the set this check grades HIGH.

Questions

If a stable VS Code ignores the declaration, why does RepoGates score it? Two reasons. A fork or an Insiders build may not ignore it — the allowlist is compiled into each build, and the build you run is not necessarily the one that ignores this extension. And the declaration is a statement of intent: an extension that asks for everything written to the terminal, or for the user's sign-in sessions, is asking for the credential-exfiltration surface on its face, whether or not this build grants it. V8 is MEDIUM at 5 points per proposal for an extension not on the list, HIGH at 12 for the sensitive set, and a note for an extension VS Code honours.

Why are the terminal and sign-in proposals HIGH rather than MEDIUM? Because reading the terminal or the sign-in state is the credential-exfiltration surface itself. terminalDataWriteEvent is every byte written to a terminal, tokens included; terminalShellEnv is the shell's environment; authGetSessions and authSession are the user's sign-in sessions for GitHub, Microsoft and every other provider the editor knows. Eleven proposals make up the set, and each costs 12 points for an extension VS Code does not grant it to.

Where does the allowlist come from, and how current is it? From the product.json inside an installed VS Code build — the extensionEnabledApiProposals key, which is distro-only: the public repository's copy carries none. RepoGates reads it from a local install with tools/vsx_known.py into backend/policy/vsx-known-publishers.json, refreshed weekly with the diff reviewed. The copy behind this page is VS Code 1.138's: 65 extensions from 22 publishers.

Related checks

V7 Declares code execution — the check V8 refines: first that the extension executes, then what it reaches for · V16 Credential redirect — the same credential surface approached from the other side, an agent config inside the package that points keys elsewhere · C13 Editor and workspace config — the repository-side editor surface, the .vscode/ configs that run when a workspace opens · C21 Credential redirect — the repository-side original of the token-exfiltration class V8's sensitive set is graded against.

Add RepoGates to Chrome Pricing

Numbers on this page: the 18 September 2026 measurement of the 100 most-installed extensions on the VS Code Marketplace, run locally through the same code as /v1/vsx/score; the proposed-API allowlist as read from a local VS Code 1.138 install on the same day; campaign facts for Koi Security's research as quoted by BleepingComputer and The Hacker News; weights from the product's scoring table.