* chat: negotiate managed settings client compatibility Report the VS Code managed-settings client version, securely transport the User-Agent, parse compatibility responses, and preserve fail-closed state across refreshes.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: simplify managed settings client identity Use the existing browser-safe Editor-Version convention from productService and remove the dedicated User-Agent IPC transport. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: report bundled Copilot runtime version Send the runtime version from product metadata alongside the VS Code editor identity and include both values in policy diagnostics. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: align peer chat sandbox expectation Use the shared sandbox config builder introduced on main so the peer-chat assertion follows the current sandbox semantics. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: use standard AI feature gate for compatibility Route managed-settings compatibility failures through the existing entitlement hidden state instead of bespoke chat and Agents-window blocking.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: apply compatibility to policy gate context Drive both the standard policy-gate context and entitlement hidden state when managed-settings compatibility is rejected, and cover their combined transitions.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: show minimum compatible client version Include the server-provided minimum client version in the managed-settings update notification, with a fallback for malformed responses.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * chat: show compatibility warning as modal Use the built-in VS Code modal dialog for managed-settings compatibility lockout while preserving update, learn-more, close, and keyboard-dismiss actions.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: add managed settings compatibility mock responses Add 404 and client_update_required presets plus configurable response status support to the local policy server.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: fix managed settings mock controls Reset schema-generated examples to a successful response and document that selected presets must be applied. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: allow managed settings client identity header Permit Editor-Version in mock endpoint CORS preflights so local testing matches the simplified client contract. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: allow Copilot runtime identity header Permit Copilot-Runtime-Version in mock endpoint CORS preflights alongside Editor-Version. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * test: expose mock response status Show and edit each mock endpoint's HTTP response status in the GUI, validate the supported range, and autosave it with the response body.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Dmitriy Vasyura <dmitriv@microsoft.com>
Mock Copilot policy endpoints
A standalone dev tool that mocks the Copilot policy endpoints that
DefaultAccountService
(src/vs/workbench/services/accounts/browser/defaultAccount.ts) calls, so you
can exercise the entitlement / token / MCP-registry / managed-settings (policy)
pipeline locally without the real GitHub backend.
It is not part of the shipped product — it is a local Node server + web GUI.
What it mocks
| Endpoint | Path | product.json key |
Response |
|---|---|---|---|
| Entitlements | /copilot_internal/user |
entitlementUrl |
IEntitlementsData (chat_enabled, copilot_plan, cloud_session_storage_enabled, …) |
| Token | /copilot_internal/v2/token |
tokenEntitlementUrl |
{ token: "agent_mode=1;editor_preview_features=1;mcp=1;…:sig" } |
| MCP registry | /copilot/mcp_registry |
mcpRegistryDataUrl |
{ mcp_registries: [{ url, registry_access }] } |
| Managed settings | /copilot_internal/managed_settings |
managedSettingsUrl |
IManagedSettingsResponse (enterprise settings.json) |
The flow is gated: the token and managed settings are only fetched when
entitlements report chat_enabled: true, and the MCP registry only when the
token enables mcp.
Usage
npm run mock-policy-server # starts on http://127.0.0.1:3000
npm run mock-policy-server -- --port 4000
npm run mock-policy-server -- --schema ./copilot-agent-runtime/schema/managed-settings-schema.json
- Open the printed GUI URL.
- Pick an endpoint tab, choose a preset and click Apply, or edit the HTTP status code and JSON response body.
- Click Wire all endpoints to point
product.overrides.jsonat this server. - Reload Code OSS (running from sources, so
VSCODE_DEVis set). - Sign in with your GitHub/Copilot account.
- Run Developer: Sync Account Policy (forces a refresh).
- Run Developer: Policy Diagnostics to inspect the applied values.
Click Unwire to restore the original URLs.
Managed-settings schema
The GUI loads the managed-settings JSON schema and, on the Managed Settings
tab, warns about top-level keys that are not declared in it (mirroring how
projectManagedSettings drops undeclared keys). The schema source is resolved in
this order:
--schema <url | file-uri | path>CLI flagMANAGED_SETTINGS_SCHEMAenvironment variable- Default:
./copilot-agent-runtime/schema/managed-settings-schema.json, resolved against the app's current working directory (normally the vscode repo root, where the schema repo sits side-by-side).
http(s):// URLs and file:// URIs are both accepted; relative paths are
resolved from the cwd. The schema is re-read on every Refresh, so you can
edit it without restarting the server. A missing schema is non-fatal — the GUI
just shows the resolved path and skips schema validation.
The Managed Settings tab includes presets for 200, 404, and the compatibility rejection contract:
{
"error_code": "client_update_required",
"client_id": "vscode",
"client_version": "1.132.0",
"minimum_client_version": "1.133.0"
}
Select Client update required (466) and click Apply. The control API also accepts
{ "endpoint": "managedSettings", "status": 466, "body": { ... } } at
POST /api/state.
How wiring works
src/bootstrap-meta.ts merges product.overrides.json over product.json with
a shallow, top-level Object.assign, only when VSCODE_DEV is set, and the file
is git-ignored. To override nested keys the tool writes back the entire
defaultChatAgent object (seeded from product.json) with only the four
endpoint URLs flipped, preserving every other key. Unwiring restores those URLs
to their product.json values and removes the file if nothing else remains.
Caveats
- Works for the default (github.com) provider path, which reads these URLs directly from config. The enterprise provider derives some URLs from the enterprise host instead.
- You must be signed in; the fetch only fires for an authenticated account.
- Overrides require a reload and only apply when running from sources.
- The server ignores the
Authorizationheader — any token is accepted.
Files
server.js— zero-dependency Nodehttpserver (endpoints + control API + schema loader + static).endpoints.js— shared endpoint definitions and presets (used by server and GUI).public/— the web GUI (index.html,app.js,style.css).