Enterprise Policies and AI Settings

Purpose and Scope

Enterprise policy management in VS Code is about making configuration predictable at organization scale. A normal user setting expresses a developer preference; a policy expresses an administrative decision that should win over default, user, and workspace values. This distinction matters because VS Code has many configuration surfaces: JSON settings files, the graphical Settings editor, extension-contributed settings, command-line launch options, and feature-specific state such as Copilot entitlements. This page connects that user-facing model to the source-backed surfaces in this repository that shape editor settings, code actions on save, Copilot public-code reference behavior, and diagnostic entrypoints for managed environments.

Sources: src/vs/code/electron-main/main.ts, src/vs/workbench/contrib/codeEditor/browser/editorSettingsMigration.ts

The source evidence for this page is intentionally centered on the places where policy-sensitive behavior becomes observable. The Electron main process imports and composes configuration-related services during startup, which makes it part of the desktop path that eventually reads environment, product, command-line, and configuration state. The workbench editor settings migration code shows how settings keys are kept compatible across versions, which is important for administrators because a managed fleet can span release trains. The editor code-action types define the vocabulary behind settings such as code actions on save, and the Copilot code-referencing module shows a concrete AI feature controlled by authentication-token capabilities rather than a local preference alone.

Sources: src/vs/code/electron-main/main.ts, src/vs/workbench/contrib/codeEditor/browser/editorSettingsMigration.ts, src/vs/editor/contrib/codeAction/common/types.ts, extensions/copilot/src/extension/completions-core/vscode-node/extension/src/codeReferencing/index.ts

Relevant Source Files

• src/vs/workbench/contrib/codeEditor/browser/editorSettingsMigration.ts — registers migrations for editor.* configuration keys so editor settings can evolve while preserving user and managed configuration intent.
• src/vs/editor/contrib/codeAction/common/types.ts — defines code-action kinds, filters, auto-apply modes, and trigger sources used by editor actions such as quick fixes, source actions, fix-all, and organize imports.
• cli/src/bin/code/main.rs — implements the Rust code launcher path, command dispatch, CLI data directory migration, and agent-related commands useful for administration and diagnostics.
• extensions/copilot/src/extension/completions-core/vscode-node/extension/src/codeReferencing/index.ts — enables or disables Copilot public-code reference tracking based on Copilot token capabilities.
• src/vs/code/electron-main/main.ts — is a desktop main-process entrypoint that wires environment, launch, file, lifecycle, logging, product, and configuration services.
• .vscode/extensions/vscode-selfhost-import-aid/.vscode/settings.json — provides a concrete workspace settings example for formatting and organize-imports behavior.

Configuration Model and Policy Boundaries

VS Code settings are normally layered by scope: defaults ship with the product, user settings apply globally for a person, and workspace settings live with a project. Enterprise policies sit above those scopes. When an administrator deploys a managed value, the policy should define the effective value regardless of what a developer put in user or workspace JSON. That does not mean every feature has a policy-specific source file in this page; rather, the repository surfaces shown here demonstrate the kinds of configuration data that policy enforcement must stabilize: editor behavior, automatic source actions, startup paths, and AI capabilities.

Sources: .vscode/extensions/vscode-selfhost-import-aid/.vscode/settings.json, src/vs/code/electron-main/main.ts

The workspace settings example is small but representative. It sets editor.formatOnSave to true, selects vscode.typescript-language-features as editor.defaultFormatter, and configures editor.codeActionsOnSave so source.organizeImports runs with the value always. In an unmanaged project this is a team convenience: everyone opening that workspace gets the same formatting and import organization defaults. In a managed organization, an administrator may choose to enforce related settings so that workspace-level preferences cannot relax required behavior. The exact precedence and deployment mechanisms are product policy concerns; the source-backed point is that these settings map to real editor and code-action concepts.

Sources: .vscode/extensions/vscode-selfhost-import-aid/.vscode/settings.json, src/vs/editor/contrib/codeAction/common/types.ts

Settings migrations are another important enterprise concern. The workbench migration registration maps EditorSettingMigration.items into configuration migrations for keys prefixed with editor.. Each migration receives the old value, reads related editor.* keys through an accessor, writes replacement key/value pairs through an ISettingsWriter, and returns ConfigurationKeyValuePairs. This keeps configuration evolution explicit instead of silently abandoning old keys. For administrators, that means a setting that was deployed or documented under an older name can be migrated through the same configuration infrastructure that user settings use, reducing the operational risk of upgrading a managed VS Code estate.

Sources: src/vs/workbench/contrib/codeEditor/browser/editorSettingsMigration.ts

AI Settings, Entitlements, and Code Referencing

AI settings are not only local JSON values. Some Copilot behavior depends on account state, tenant policy, product entitlements, and service-issued token claims. The CodeReference class is a clear example. It registers a listener with onCopilotToken, ignores that listener while running in tests, and updates its enabled field when a token arrives. The feature is enabled only when token.codeQuoteEnabled is true. If that capability is absent, existing subscriptions are disposed, the field is reset through the disabled path, and a debug log records that public code references are disabled.

Sources: extensions/copilot/src/extension/completions-core/vscode-node/extension/src/codeReferencing/index.ts

This design is useful to understand when troubleshooting enterprise AI settings. A developer might look for a local setting and find none, because the decisive signal for public code references is the Copilot token capability. When codeQuoteEnabled is true, the module logs that public code references are enabled and creates a CodeRefEngagementTracker through the instantiation service. When it is false, the tracker is not active. That makes the authentication service, token notifier, runtime mode service, log target, and instantiation service part of the observable control plane for this AI feature.

Sources: extensions/copilot/src/extension/completions-core/vscode-node/extension/src/codeReferencing/index.ts

The same principle applies more broadly to enterprise AI administration: local configuration, account authentication, and service-managed capabilities can all participate in the final behavior. Policies are appropriate for settings that should be locked on the client. Entitlements are appropriate for capabilities issued by Copilot services. Logs are appropriate for confirming what the client decided at runtime. The source path here does not document every Copilot policy, but it does show a concrete boundary: public-code reference engagement is created only after the token reports that code quoting is enabled.

Sources: extensions/copilot/src/extension/completions-core/vscode-node/extension/src/codeReferencing/index.ts

Code Actions, Save-Time Automation, and Managed Editing Rules

Code actions are editor operations offered by language features and extensions. The repository defines well-known hierarchical kinds such as quickfix, refactor, refactor.extract, refactor.inline, refactor.move, refactor.rewrite, notebook, source, source.organizeImports, source.fixAll, and refactor.surround. These names matter because settings and UI surfaces frequently refer to them as strings. The workspace example uses source.organizeImports, and the type definitions establish that it is a source action under the broader source hierarchy.

Sources: src/vs/editor/contrib/codeAction/common/types.ts, .vscode/extensions/vscode-selfhost-import-aid/.vscode/settings.json

The filtering functions show how VS Code decides which actions are eligible for a request. mayIncludeActionsOfKind checks whether an offered kind intersects with the filter include value, applies excludes, and deliberately avoids returning source actions unless includeSourceActions is set. filtersAction applies similar checks to an actual languages.CodeAction, including the optional onlyIncludePreferredActions flag. This is significant for administrators and extension authors because save-time automation should be explicit. Source actions such as organize imports and fix-all can change files, so the filtering contract prevents them from being mixed into generic quick-fix flows unless requested.

Sources: src/vs/editor/contrib/codeAction/common/types.ts

CodeActionAutoApply also captures a policy-relevant distinction. ifSingle means auto-apply only when one candidate exists, first means select the first candidate, and never disables automatic application. CodeActionTriggerSource records where an action request came from, including refactor, lightbulb, source action, quick fix, fix all, organize imports, auto fix, quick-fix hover, save participants, and the Problems view. Together these names form a compact behavioral vocabulary for settings, logs, telemetry, and tests that need to explain why an edit happened and whether it was user-triggered or save-triggered.

Sources: src/vs/editor/contrib/codeAction/common/types.ts

CLI, Startup, and Diagnostic Surfaces

The code command is another practical part of enterprise management because it determines how users and automation launch VS Code. The Rust entrypoint collects raw arguments, tries legacy parsing, chooses integrated or standalone parsing, migrates launcher paths through LauncherPaths::migrate, and constructs a CommandContext with an HTTP client, paths, logger, and parsed arguments. For normal launches and extension/status commands, it converts parsed options into base Code arguments and starts the desktop experience. That path is relevant when administrators need a consistent data directory, repeatable launch flags, or predictable logging behavior.

Sources: cli/src/bin/code/main.rs

The same CLI dispatch also exposes agent and remote-oriented commands. The match arms include serve-web, tunnel command shell handling, version switching and display, extension command forwarding, status, and agent subcommands such as ps, host, stop, kill, and logs. For enterprise AI troubleshooting, agent logs and related process commands provide a command-line control surface that complements graphical settings and product logs. The source does not prescribe an administrative policy, but it does show the command names and the separation between parsed CLI state, logging installation, and command-specific execution.

Sources: cli/src/bin/code/main.rs

Desktop startup provides the other side of that story. The Electron main process imports configuration, environment, diagnostics, file service, lifecycle, logging, product, launch, IPC, and argument parsing modules before constructing the application path. That makes it the correct layer to understand when a setting appears to behave differently at process launch than after the workbench is open. Enterprise administrators often debug issues by separating launch-time concerns, such as command-line flags and environment, from workbench concerns, such as settings migrations and editor behavior. The source layout reflects that separation.

Sources: src/vs/code/electron-main/main.ts

Compact Reference

Surface	Concrete names	What to check
Editor settings migration	registerConfigurationMigrations, EditorSettingMigration.items, editor.*, ISettingsWriter	Whether an editor setting has a migration path when upgrading VS Code.
Code-action categories	CodeActionKind.Source, SourceOrganizeImports, SourceFixAll, QuickFix, Refactor	Whether an automated edit is a source action, quick fix, or refactor.
Code-action auto apply	CodeActionAutoApply.IfSingle, First, Never	Whether the configured behavior can apply an edit without an explicit picker choice.
Code-action filtering	include, excludes, includeSourceActions, onlyIncludePreferredActions	Whether source actions are deliberately included in the request.
Workspace example	editor.formatOnSave, editor.defaultFormatter, editor.codeActionsOnSave, source.organizeImports	Whether project settings request formatting or import organization on save.
Copilot code references	CodeReference.register, onCopilotToken, codeQuoteEnabled, CodeRefEngagementTracker	Whether token capabilities enable public-code reference tracking.
CLI diagnostics	agent ps, agent host, agent stop, agent kill, agent logs, status	Which command-line surface can inspect or control agent-related runtime state.

Operational Guidance and Next Steps

When validating a managed VS Code deployment, start by identifying which layer owns the behavior. If the issue is a formatting or import rule, inspect the effective settings and map them to the code-action vocabulary. If the issue is a changed editor setting after upgrade, check whether it belongs to the migrated editor.* family. If the issue is Copilot public-code references, confirm authentication and token capability rather than looking only at workspace JSON. If the issue is startup or agent diagnostics, reproduce through the code CLI so launch arguments, data directories, and logs are explicit.

Sources: src/vs/workbench/contrib/codeEditor/browser/editorSettingsMigration.ts, src/vs/editor/contrib/codeAction/common/types.ts, cli/src/bin/code/main.rs, extensions/copilot/src/extension/completions-core/vscode-node/extension/src/codeReferencing/index.ts, src/vs/code/electron-main/main.ts, .vscode/extensions/vscode-selfhost-import-aid/.vscode/settings.json

For adjacent reading, use the settings and keybindings material to understand the normal configuration experience before adding policy enforcement. Use the Copilot and AI overview for the broader AI feature set, then return to this page when you need to distinguish client settings from service-issued capabilities. Use the command-line interface page when diagnosing launch behavior or agent logs from automation. That sequence keeps the mental model simple: define the user-facing setting, identify the source-backed feature contract, then decide whether the value should be a local preference, workspace convention, enterprise policy, or Copilot entitlement.