fix: accept already-selected session type when picker declines to open (build fix for vscode-engineering#3899)

Build failure

The Electron smoke suite is red on main (definition 111, builds .32/.33). One test fails consistently:

Agents Window (SSH Dev Container AgentHost) › Starts and reopens a Dev Container session over SSH
Error: Session type "Copilot" not found in picker. Available:
    at AgentsWindow.selectSessionType (test/automation/out/agentsWindow.js)

The Available: list is blank — the session-type dropdown rendered zero rows in the single-host SSH Dev Container scenario, so this is an empty/unpopulated picker rather than a label mismatch.

Root cause

The recent change to the unified remote host picker updated the smoke test to call
selectSessionType('Copilot', { providerLabel: fixture.name }) and reworked
test/automation/src/agentsWindow.ts so that when providerLabel is supplied it
skips the "already selected" short-circuits and always tries to force the
dropdown open (!providerNeedle && await this.isSessionTypeSelected(label)).

In the SSH Dev Container scenario there is only a single session type ("Copilot")
for the one connected host, and it is already the selected pick. The product
picker deliberately refuses to open in that case — _showPicker returns early
when folderTypes.length <= 1 && this._pickServedByFolder(this._picked) in
src/vs/sessions/contrib/chat/browser/sessionTypePicker.ts. Because the dropdown
never renders, the automation's row poll always sees an empty list, so on the
final attempt it throws Session type "Copilot" not found in picker. Available:
with a blank list — exactly the observed failure.

The product behavior (not opening a single-option picker that has nothing to
disambiguate) is correct. The defect is that the automation helper treats a
never-opened, single-option picker as a hard failure when the requested type is
already selected.

How the fix works

In AgentsWindow.selectSessionType, before throwing on the final attempt, the
helper now checks isSessionTypeSelected(label). When the requested session type
is already the active selection (the single-host case where the picker
legitimately declines to open), it returns successfully instead of throwing on an
empty picker. The multi-host disambiguation path via providerLabel is
unchanged: when the dropdown does open with section headers, the existing
provider-scoped matching still runs, and a genuinely missing type still throws
with the observed rows.

Rollback evaluation

Recommendation: Do not roll back.

Culprit: 3298d39442574eaf117c8560dfdb1ce3be557e13 (PR microsoft/vscode#336648, "sessions: Fix unified remote host picker behavior").

Rationale: The fix-forward is a small, self-contained change to a single smoke
automation helper and preserves the intended "unified remote host picker"
product behavior. Reverting the culprit would discard that product fix and its
dependent picker/provider changes for no benefit, since the underlying product
picker behaves correctly. The change is bounded and low risk, so fixing forward
is clearly preferable.

Owners to consult: @meganrogge

Validation

Source-level inspection only. node_modules/tsc and git commit are not
available in this environment, so the automation project could not be compiled
or the smoke test executed here. The change reuses the existing
isSessionTypeSelected helper and adds no new symbols, keeping it type-safe by
construction. The single-host SSH Dev Container path now succeeds when the type
is already selected; the multi-host disambiguation path is unchanged.

Risk

Low. The change only affects the terminal failure branch of one automation
helper and narrows a false failure. It cannot mask a real regression: it only
returns early when the requested session type is already the selected pick,
which is the intended state for that scenario.

Recommended reviewer

Recommended owner: @meganrogge

Fixes microsoft/vscode-engineering#3899

Generated by build-fix · opus48 · 596.5 AIC · ⌖ 19.6 AIC · ⊞ 9.7K · ◷

[!NOTE]
This was originally intended as a pull request, but PR creation failed. The changes have been pushed to the branch fix/ssh-devcontainer-session-picker-3899-6cf80d5cb715783e.

Original error: ERR_API: [2026-09-18T20:22:58.014Z] create pull request in microsoft/vscode failed (attempt 1)

Original error: Validation Failed: {"resource":"PullRequest","field":"head","code":"invalid"} - https://docs.github.com/rest/pulls/pulls#create-a-pull-request
Retryable: false
Suggestion: This error cannot be resolved by retrying. Please check the error details and fix the underlying issue.

To create the pull request manually:

gh pr create --title "fix: accept already-selected session type when picker declines to open (build fix for vscode-engineering#3899)" --base main --head vscodebot-pr:fix/ssh-devcontainer-session-picker-3899-6cf80d5cb715783e --repo microsoft/vscode

From bb22109e51b7f4e10adf40c8480dfcf5da49b827 Mon Sep 17 00:00:00 2001
X-GH-AW-Base-Commit: 025a3ca5ca6934960d671eaa4547b130d56f57aa
From: Ladislau Szomoru <3372902+lszomoru@users.noreply.github.com>
Date: Fri, 18 Sep 2026 21:51:35 +0200
Subject: [PATCH] Agents - Implement "Sync Changes" visibility for folder
 sessions only (#336817)

* Agent Host changes for lszomoru/agents/sync-changes-folder-session-logic

* Agents - clarify Sync Changes availability

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../changes/browser/sessionSyncChanges.ts     | 18 ++++---
 .../test/browser/sessionSyncChanges.test.ts   | 47 +++++++++++++++++--
 .../browser/sessionsChatAccessibilityHelp.ts  |  2 +-
 3 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/src/vs/sessions/contrib/changes/browser/sessionSyncChanges.ts b/src/vs/sessions/contrib/changes/browser/sessionSyncChanges.ts
index 96b7df5e453..b3b7d38092f 100644
--- a/src/vs/sessions/contrib/changes/browser/sessionSyncChanges.ts
+++ b/src/vs/sessions/contrib/changes/browser/sessionSyncChanges.ts
@@ -25,7 +25,7 @@ import { SessionIdContext } from '../../../common/contextkeys.js';
 import { ISessionContext } from '../../../services/sessions/browser/sessionContext.js';
 import { ISessionsPartService } from '../../../services/sessions/browser/sessionsPartService.js';
 import { ISessionsService } from '../../../services/sessions/browser/sessionsService.js';
-import { ISession, ISessionChangeset, ISessionChangesetOperation, SessionChangesetOperationScope, SessionChangesetOperationStatus, UNCOMMITTED_CHANGES_CHANGESET_ID } from '../../../services/sessions/common/session.js';
+import { getSessionWorkspaceKind, ISession, ISessionChangeset, ISessionChangesetOperation, SessionChangesetOperationScope, SessionChangesetOperationStatus, SessionWorkspaceKind, UNCOMMITTED_CHANGES_CHANGESET_ID } from '../../../services/sessions/com
... (truncated)

Start in test/automation/src/agentsWindow.ts at AgentsWindow.selectSessionType and review the failing Electron smoke scenario described in the issue. Check the existing isSessionTypeSelected helper and run the relevant automation or smoke test if available. Done means an already-selected single-host session type succeeds without an empty-picker error, while multi-host provider matching and genuine missing-type failures remain intact.