Synced extensions do not respect VS Code profiles.

[PhiProven]

Issue Description

The synced extensions file shows several undesired interactions with respect to VS Code profiles

• The Apply Extension to all Profiles flag is not recorded in the synced data
• The enabled/disabled flags seem to record the state of the current workspace/profile rather than the state of the Default VS Code profile. This is in contrast to other resources like settings which correspond to the Default VS Code profile.
• Extensions only installed in a custom VS Code profile still show up in the synced extensions file as disabled extensions

Expected Behavior

The extensions resource should record the state of extensions of the Default VS Code profile, analogous to how settings records the settings of the Default profile, rather than the VS Code profile applied in the current workspace.
Moreover, the Apply Extension to all Profiles flag must be recorded in this file.

Actual Behavior

• The Apply Extension to all Profiles flags are lost through syncing.
• Extensions are moved between the enabled/disabled section when switching VS Code profiles, even though their configuration in the Default profile is untouched. This seems related to
  • Bug/feature: Awareness of workspace-specific extension enabling/disabling #95
  • Confused about extensions.yml #70
• Extensions which are not installed in the Default VS Code profile but other custom profiles still show up as disabled extensions. This seems related to
  • Certain extensions lose their uuid when disabled #110
  • Confused about extensions.yml #70

Reproduction Steps

• For the Apply Extension to all Profiles flag
  • Apply Extension to all Profiles for some extension E in the VS Code UI
  • Sync your settings and extensions (user -> repository)
  • Uninstall extension E
  • Pull your settings and extensions (repository -> user)
  • Observe that extension E is reinstalled but the Apply Extension to all Profiles flag is no longer set
• For extensions recording the state of the current workspace/profile
  • Make sure that you are in a clean settings state (Sync Settings: View differences between actual and saved settings shows no differences)
  • Switch to a custom VS Code profile that has a different set of extensions installed/enabled
  • Run the diff again and observe that extensions are moved between the enabled/disabled section, even though no actual config changes happened
• For non installed extensions showing up
  • Switch to a custom VS Code profile and install some extension E
  • Switch to the Default profile and observe that extension E does not show up as installed extension in the VS Code UI
  • Run Sync Settings: View differences between actual and saved settings
  • Observe that extension E shows up as disabled extension in the generated extensions file

Version

0.21.0

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[cookesan]

This also looks source-backed. The extension sync model is not profile-aware enough to preserve the VS Code profile metadata you describe.

The serialized extensions.yml is built from listEditorExtensions(). For VS Code, that walks vscode.extensions.all, reads the extension install data directory and extensions.json, and then categorizes extensions into enabled, disabled, and builtin.disabled. I do not see any field in that serialized model for VS Code's "Apply Extension to all Profiles" state.

The restore side also uses global VS Code commands:

workbench.extensions.installExtension
workbench.extensions.enableExtension
workbench.extensions.disableExtension

Those calls do not carry profile/all-profiles metadata in this code. That explains why the all-profiles flag is lost after uninstall/reinstall.

The "custom-profile-only extension appears as disabled" behavior also follows from the current scan: extensions present on disk but not active in vscode.extensions.all are treated as disabled. With VS Code profiles, that can mean "installed for another profile", not "disabled in the default profile".

So I would treat this as a profile-support bug/feature gap. Syncing the profiles resource may preserve profile files, but the extensions resource itself likely needs a richer profile-aware schema if it is expected to round-trip per-profile installs/enabled state and the all-profiles flag.

[daiyam]

workbench.extensions.enableExtension
workbench.extensions.disableExtension

Those 2 commands aren't even available on regular VSCode...

[daiyam]

VSCode only allows to globally install/uninstall an extension. I'm doing some trickeries to be able to enable (uninstall/install) or uninstall (write to db requiring an restart).
There is no commands to manage those states. Some have tried to have those kind of commands in VSCode but it's in limbo (microsoft/vscode#40239, microsoft/vscode#201672).
I can't have as much control as VSCode profiles provide. Sadly, this is a limitation of VSCode.

[cookesan]

Good catch on those commands. I overstated the restore path there.

With VS Code not exposing profile-aware enable/disable commands, your explanation matches the practical limit: extension install state can be approximated globally, but per-profile enablement/all-profiles metadata cannot be round-tripped cleanly through the current command surface.