Disable bg=true update parameter for Visual-Studio-Code organization accounts

[Copilot]

Disables the bg=true query parameter in update check URLs when the user's default account contains Visual-Studio-Code in its organization_login_list. Once disabled, progressive releases remain permanently disabled.

Changes

Architecture

• Workbench contribution (DefaultAccountUpdateContribution) monitors IDefaultAccountService for account changes
• Communicates disable state to main process via IPC (UpdateChannel)
• Platform update services (Windows/macOS/Linux) check flag before setting background: true in update URLs

Implementation

• Added IUpdateService.disableProgressiveReleases(): Promise<void> method (no parameters)
• AbstractUpdateService tracks state in _disableProgressiveReleases field with sticky behavior
• Sticky state: Once disableProgressiveReleases() is called, the disabled state becomes permanent
• Simplified API: No boolean parameter needed since it's a one-way disable operation
• Contribution registered at LifecyclePhase.Eventually for early execution
• Checks on startup and listens for onDidChangeDefaultAccount events
• Uses exact match (case-insensitive) for 'visual-studio-code' organization login
• Electron-only (early return on isWeb)
• Method returns Promise<void> to ensure completion after IPC channel traversal

Flow

DefaultAccountUpdateContribution
  → getDefaultAccount()
  → organization_login_list.some(org => org.toLowerCase() === 'visual-studio-code')
  → if shouldDisable: await disableProgressiveReleases() [IPC]
    → AbstractUpdateService._disableProgressiveReleases = true
    → Once set, remains true permanently
      → doCheckForUpdates: background = !explicit && !shouldDisableProgressiveReleases()
        → buildUpdateFeedUrl: bg=true omitted when disabled

Changes span 10 files: service interfaces, IPC layer, platform implementations, and workbench contribution.

Original prompt

1. yup sounds good
2. I bet it wont be available on startup. do it as early as you can, but check for events too
3. Electron only yeah

[Chronological Review: The conversation began with the user requesting to disable the `bg=true` parameter for users whose default account contains `Visual-Studio-Code` in the `organization_login_list`. The user asked for a workbench contribution that listens for changes in the default account and propagates that state to the main process update service. The user then confirmed the approach, indicating that it should be done as early as possible and also check for events. The user specified that the implementation should be limited to Electron only.]

[Intent Mapping:

1. "I need to disable the bg=true parameter when checking for updates for all users whose default account contains Visual-Studio-Code in the organization_login_list." - User's primary request for functionality.
2. "Figure out a workbench contribution within the update domain that listens and reacts to default account changes..." - User's request for a specific implementation strategy.
3. "yup sounds good" - User's confirmation of the proposed approach.
4. "I bet it wont be available on startup. do it as early as you can, but check for events too." - User's guidance on timing and event handling.
5. "Electron only yeah" - User's specification for the technology stack.]

[Technical Inventory:

• Technologies: TypeScript, Electron
• Framework: VS Code workbench contributions
• Architectural Decisions: Listening for default account changes and propagating state to the update service.]

[Code Archaeology:

• File: /Users/joao/Work/vscode/src/vs/workbench/contrib/update/browser/update.ts
• Relevant Code: The user is working on implementing functionality related to update checks based on user accounts.]

[Progress Assessment:

• Completed: User has articulated the requirements for the feature.
• Pending: Implementation of the workbench contribution that listens for default account changes and modifies the update behavior accordingly.]

[Context Validation: All necessary context for continuing the work on the update feature is captured, including user requirements and technical specifications.]

[Recent Commands Analysis:

• Last Agent Commands: The user provided specific requests and confirmations regarding the implementation strategy.
• Tool Results Summary: No specific tool results were returned as the conversation focused on user requests and clarifications.
• Pre-Summary State: The agent was actively discussing the implementation of a feature in the update.ts file when the token budget was exceeded.
• Operation Context: The commands were executed in response to the user's requests for a specific feature implementation related to update checks.]

1. Conversation Overview: - Primary Objectives: - "I need to disable the bg=true parameter when checking for updates for all users whose default account contains `Visual-Studio-Code` in the organization_login_list." - "Figure out a workbench contribution within the update domain that listens and reacts to default account changes..." - Session Context: The user is focused on implementing a feature in the VS Code update process that reacts to changes in user accounts. - User Intent Evolution: The user confirmed the approach and provided additional specifications regarding timing and technology.

2. Technical Foundation:

• TypeScript: Used for implementing the feature.
• Electron: Specified as the technology stack for the implementation.
• VS Code Workbench Contributions: The architectural pattern to be used for listening to account changes.

3. Codebase Status:

• File Name: update.ts
• Purpose: To manage update checks based on user account information.
• Current State: User is in the process of defining how to implement the feature.
• Key Code Segments: Not specified yet, as the implementation is still in the planning phase.

4. Problem Resolution:

• Issues Encountered: None explicitly stated; focus is on planning the implementation.
• Solutions Implemented: User has provided clear requirements and specifications.
• Debugging Context: No ongoing troubleshooting mentioned.
• Lessons Learned: User's specifications indicate a need for early execution and event handling.

5. Progress Tracking:

• Completed Tasks: User has articulated the requirements for the feature.
• Partially Complete Work: Implementation of the workbench contribution is pending.
• Validated Outcomes: None yet, as the feature is still in the planning stage.

6. Active Work State:

• Current Focus: Implementing a feature in update.ts that disables bg=true based on user account conditions.
• Recent Context: User has confirmed the approach and provided additional specifications.
• Working Code: No specific code snippets discussed recently.
• Immediate Context: User is focused on how to implement the feature effectively.

7. Recent Operations:

• Last Agent Comma...

Created from VS Code.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[joaomoreno]

@copilot Make the changes suggested. Also let's rename setDisableBackgroundUpdates to disableProgressiveReleases

[Copilot]

@copilot Make the changes suggested. Also let's rename setDisableBackgroundUpdates to disableProgressiveReleases

Renamed to disableProgressiveReleases and changed return type to Promise<void> for proper IPC traversal. See commit 4fdfefe.

[joaomoreno]

@copilot Let's just ensure this gets disabled once: as soon as the update service gets called this new method, it should always keep that state as disabled.

[Copilot]

@copilot Let's just ensure this gets disabled once: as soon as the update service gets called this new method, it should always keep that state as disabled.

Implemented sticky behavior - once disableProgressiveReleases(true) is called, the state remains disabled permanently. Subsequent calls with false will not re-enable it. See commit d3275a6.

[Copilot]

Pull request overview

Disables the bg=true update-check query parameter for users whose default account indicates membership in the Visual-Studio-Code organization by propagating a “disable progressive releases” flag from the workbench (renderer) to the Electron main process update service.

Changes:

• Added disableProgressiveReleases(disable: boolean): Promise<void> to IUpdateService and wired it through the update IPC channel.
• Implemented sticky “disable progressive releases” state in AbstractUpdateService and used it to prevent bg=true from being added to update URLs on Windows/macOS/Linux.
• Added a workbench contribution that monitors IDefaultAccountService and triggers the disable behavior for matching accounts (Electron-only).

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/vs/workbench/services/update/browser/updateService.ts	Adds a browser no-op implementation of the new IUpdateService API.
src/vs/workbench/contrib/update/browser/update.ts	Adds DefaultAccountUpdateContribution to detect org membership and invoke disableProgressiveReleases via the update service.
src/vs/workbench/contrib/update/browser/update.contribution.ts	Registers the new workbench contribution.
src/vs/platform/update/electron-main/updateService.win32.ts	Uses the new disable flag to avoid bg=true in update feed URLs.
src/vs/platform/update/electron-main/updateService.linux.ts	Uses the new disable flag to avoid bg=true in update feed URLs.
src/vs/platform/update/electron-main/updateService.darwin.ts	Uses the new disable flag to avoid bg=true in update feed URLs.
src/vs/platform/update/electron-main/abstractUpdateService.ts	Tracks the sticky disable state and exposes shouldDisableProgressiveReleases().
src/vs/platform/update/electron-main/updateService.snap.ts	Adds a snap no-op implementation of the new IUpdateService API.
src/vs/platform/update/common/updateIpc.ts	Adds IPC command + client method for disableProgressiveReleases.
src/vs/platform/update/common/update.ts	Extends IUpdateService with disableProgressiveReleases.