Skip to content

Feature Request: Allow telemetry.telemetryLevel to be overridden at workspace scope (or new workspace-scope setting) #323825

Description

@chirag127

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.126

OS Version: Windows 11 Enterprise (26200) — corporate managed

Steps to Reproduce

  1. In a project workspace that handles customer/regulated data, open .vscode/settings.json.
  2. Add "telemetry.telemetryLevel": "off".
  3. Observe the setting is ignored — value only takes effect when placed in User (application) settings.

The problem

telemetry.telemetryLevel is registered with ConfigurationScope.APPLICATION and restricted: true (see src/vs/platform/telemetry/common/telemetryService.ts). This means:

  • A developer working on multiple projects on a corporate-managed machine cannot say "telemetry off for this workspace (which contains customer data under NDA) but leave the org-wide policy value in place for other projects."
  • The only escape hatches today are the org-wide GPO/enterprise policy (TelemetryLevel), or flipping the user setting each time you switch projects — both are heavy hammers.

Peer editors solve this: JetBrains IDEs allow project-level opt-out of Data Sharing that stacks over the application default. VS Code's own http.proxy, git.enabled, and other sensitive settings support workspace scope with the restricted flag gating trusted-workspace behaviour — so there is precedent for this pattern.

Proposal

Either:

(a) Widen the scope of telemetry.telemetryLevel to ConfigurationScope.WINDOW (or RESOURCE), keeping restricted: true so only trusted workspaces can lower the level. The value would monotonically decrease telemetry (workspace can only set ≤ application level) — never raise it above what the user/policy allows.

(b) Add a new sibling setting e.g. telemetry.workspaceOverride (enum: inherit | off, default inherit, scope WINDOW, restricted: true). off clamps the effective level to off for the window; anything else inherits the app-level value.

Option (a) is cleaner if the monotonic-decrease guarantee is acceptable. Option (b) is safer if you want to keep the primary setting application-scoped and add opt-in workspace clamp.

Why this matters for corp/enterprise use

Enterprise VS Code users with mixed public/regulated projects on the same laptop currently either:

  • Accept org-wide telemetry level for all workspaces (may leak metadata about regulated project structure).
  • Manually toggle the user setting each context switch (error-prone).

A workspace-scoped clamp gives per-project rigor without disturbing the org-wide baseline.

Not a duplicate of

Searched for telemetry workspace scope, telemetry.telemetryLevel workspace, telemetry per workspace project — no existing issue captures this ask. #260375 covers tool enablement, not telemetry scope. If I missed one, happy to close.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions