Sign in to use Copilot is no-op

[osortega]

Testing #323186

1. code-insiders --transient
2. Try signing in from the model picker action

Screen.Recording.2026-06-29.at.10.44.50.AM.mov

[dmitrivMS]

That's not the one I added I believe, but I'll take a look.

[lramos15]

Oh maybe this is the one @rwoll added.

So many hands adopting different things here 😅

[rwoll]

@dmitrivMS - have you been able to repro? My attempts on latest with code --transient all fail to repro:

Screen.Recording.2026-06-29.at.2.32.10.PM.mov

[dmitrivMS]

@rwoll Nope, cannot repro either...
@osortega Was there anything you did before getting to the model picker? I.e. you dismissed Welcome dialog without sign-in? Anything else?

[rwoll]

TL;DR

The Model Picker shows the "Sign in to use Copilot" affordance whenever chatRequiresSetup(...) is true. That predicate is true for a much broader set of states than "user is signed out" — including a returning user whose entitlement is cached as Free/Pro/EDU but whose completed flag is false and who currently has no live models.

But the command the button triggers (workbench.action.chat.triggerSetup) only ever shows a sign‑in dialog / performs sign‑in when the entitlement is Unknown (or sign‑in is explicitly forced). For a cached Free/Pro/EDU entitlement it deliberately takes the silent DefaultSetup path — no dialog, no sign‑in, an instant no‑op install() for an already‑installed extension.

➡️ Net effect: the button is shown to a cohort for whom it does nothing visible.

A fresh --transient window has no persisted entitlement, so the entitlement defaults to Unknown, the dialog path is taken, and the bug cannot reproduce.

Verbose Logs and Suggested Fixes

---

The exact click chain (file:line)

#	What happens	Location
1	Picker decides it is in the "setup required" state and renders the header "Sign in to use Copilot" + the action "Sign in to use Copilot..." with run: () => onRequestSetup?.()	chat/browser/widget/input/chatModelPicker.ts:505-531
2	The action is wired to _requestSetup	chatModelPicker.ts:1341-1342
3	Action‑widget click handler hides the popup, then runs the action	chatModelPicker.ts:1384-1388
4	_requestSetup() fires the command (result ignored, not awaited)	chatModelPicker.ts:1201-1203
5	CHAT_SETUP_ACTION_ID = 'workbench.action.chat.triggerSetup' Action2 runs → ChatSetup.getInstance(...).run()	chat/browser/chatSetup/chatSetupContributions.ts:230, 244, 271-272
6	ChatSetup.doRun() chooses a strategy. For Free/Pro/EDU/ProPlus → DefaultSetup (skips showDialog())	chat/browser/chatSetup/chatSetupRunner.ts:125-134 (key line 128)
7	DefaultSetup → controller.value.setup() → doSetup(): signs in only when entitlement === Unknown (or forced). Otherwise signIn = false → straight to install()	chat/browser/chatSetup/chatSetupController.ts:110-144 (key lines 120‑127)
8	install() for an already‑installed extension completes near‑instantly with no UI. Nothing appears.	chatSetupController.ts:144

What gates whether the button is shown (step 1)

• isSetupRequired() → _unavailableReason() === SetupRequired — chatModelPicker.ts:1177-1179
• getModelPickerUnavailableReason(...) returns SetupRequired when trust initialized + trusted + no live picker model + requiresSetup — chatModelSelectionLogic.ts:435-457
• requiresSetup = chatRequiresSetup({ completed, disabled, untrusted:false, entitlement, anonymous, hasByokModels }) — chatModelPicker.ts:1150-1161
• chatRequiresSetup returns true when !completed && !hasByokModels (among other branches) — chatEntitlementService.ts:186-198. This branch is entitlement‑agnostic, so a Free/Pro user with completed=false trips it.

---

Root cause

A mismatch between the condition that shows the button and the behavior of the action it triggers.

• Show condition (chatRequiresSetup) is broad: !completed, disabled, untrusted, entitlement === Available, or entitlement === Unknown → chatEntitlementService.ts:186-198.
• Action behavior only produces a visible sign‑in when entitlement === Unknown (or forceSignInDialog/forceSignIn):
  • chatSetupRunner.ts:128 — dialogSkipped || isProUser(entitlement) || entitlement === Free ⇒ DefaultSetup, bypassing showDialog(). (isProUser = EDU | Pro | ProPlus, chatEntitlementService.ts:267-269.)
  • chatSetupController.ts:120-127 — sign‑in is attempted only for entitlement === Unknown; every other entitlement is treated as "already signed in" ⇒ signIn = false.

So for entitlement ∈ {Free, EDU, Pro, ProPlus} with the button visible (i.e. completed === false and no live model), the entire downstream flow is dialog‑less and sign‑in‑less, and install() is a no‑op → the click does nothing observable.

Reproducing cohort (persisted state)

Entitlement is persisted to StorageScope.PROFILE / StorageTarget.MACHINE and restored synchronously at construction, defaulting to Unknown only when absent:

• load: chatEntitlementService.ts:1350-1355
• persist (incl. completed + entitlement together): chatEntitlementService.ts:1428-1456
• one‑time migration that itself acknowledges the installed && !completed cohort: chatEntitlementService.ts:1360-1363

A returning user can therefore hold a cached Free/Pro/EDU entitlement while completed is false and models aren't live yet (e.g. the Copilot Chat extension isn't currently installed/active, or an auth session lapsed). That is precisely the cohort that sees the button and gets the silent path.

Why --transient does NOT reproduce

A transient window has no persisted profile state → this._state falls back to { entitlement: ChatEntitlement.Unknown, ... } (chatEntitlementService.ts:1350-1351).

• chatSetupRunner.ts:128: isProUser(Unknown) and Unknown === Free are both false → falls through to else → await this.showDialog(options) (chatSetupRunner.ts:133).
• Even if a dialog button routed to DefaultSetup, chatSetupController.ts:120 sets signIn = true for Unknown.
  ➡️ The sign‑in dialog/flow always appears in a fresh window. Non‑reproducible, exactly as reported.

---

Hypotheses ranked (with cross‑check)

✅ #1 — Silent DefaultSetup for already‑entitled (cached Free/Pro) users — CONFIRMED, primary

Evidence above. Independently reached by manual trace, gpt-5.5, and gemini-3.1-pro. The discriminator vs. --transient is the persisted entitlement (Unknown ⇒ dialog; Free/Pro ⇒ silent).

⚠️ #2 — Fire‑and‑forget _requestSetup() swallows any no‑op/error — CONFIRMED, contributing

chatModelPicker.ts:1201-1203 calls executeCommand(CHAT_SETUP_ACTION_ID) without await/catch and returns void. Even when the downstream silently no‑ops or throws, the picker gives zero feedback. This converts an "unusual state" into a "button looks broken" UX. (Contrast: other callers such as chatTipContentPart.ts:144 and onboardingVariationA.ts:769 consume the returned boolean.)

⚠️ #3 — Label/affordance is hard‑coded "Sign in…" regardless of entitlement — CONFIRMED, contributing

chatModelPicker.ts:513,522,526 always say "Sign in to use Copilot" even when the user is already signed in and only needs a (silent) finalize. The text over‑promises a dialog that the logic will not show.

🟡 #4 — ChatSetup singleton pendingRun guard — POSSIBLE, secondary

chatSetupRunner.ts:60,86-88: ChatSetup is a process‑singleton (chatSetupRunner.ts:50-58) and run() returns the in‑flight promise if one exists. If a prior setup run is still pending (a dialog opened elsewhere and awaiting), a click returns that promise and opens nothing. Not the primary cause here, but another "nothing happens" path that does not exist in a fresh window.

❌ #5 — executeCommand blocked by the Action2 precondition — DISPROVEN

CHAT_SETUP_ACTION_ID has a precondition (chatSetupContributions.ts:234-240), but registerAction2 maps the handler directly to (accessor, ...args) => action.run(...) with no precondition check (platform/actions/common/actions.ts:729-733); CommandService just invokes that handler. Preconditions only affect menu/keybinding/command‑palette enablement. So the command always runs run().

❌ #6 — _actionWidgetService.hide() tears down the run — DISPROVEN

chatModelPicker.ts:1385-1387 calls hide() then action.run(). hide() is synchronous DOM teardown of the popup; the run closure (() => onRequestSetup?.()) is independent and still executes.

---

How to reproduce (conceptual)

1. Be (or have previously been) signed in such that the profile has a cached entitlement of Free/Pro/EDU/ProPlus in CHAT_ENTITLEMENT_CONTEXT_STORAGE_KEY.
2. Get into a state where sentiment.completed === false and the picker has no live model (e.g. Copilot Chat extension uninstalled/disabled/not‑yet‑activated, or session lapsed) — the picker then renders "Sign in to use Copilot".
3. Click it → silent DefaultSetup → signIn=false → no dialog. Bug reproduced.
4. Launch --transient → entitlement Unknown → dialog shows → not reproduced.

(Static analysis only; not executed, per the request not to build/run.)

---

Suggested fixes

A. Align the action with the actual state (recommended). In chatModelPicker.ts, branch on this._entitlementService.entitlement:

• If Unknown (genuinely signed out): keep "Sign in to use Copilot…" → current command is fine, or explicitly use the force‑sign‑in path ({ forceSignInDialog: true }, or the dedicated workbench.action.chat.triggerSetupForceSignIn action at chatSetupContributions.ts:324-341).
• Otherwise (already entitled, just needs finalize): relabel to e.g. "Set up Copilot…"/"Finish setup…" and ensure the silent path surfaces visible progress/confirmation.

B. Stop swallowing the result. Make _requestSetup() async, await the command, and on a falsy/no‑op result surface feedback (notification/log) instead of silently returning. chatModelPicker.ts:1201-1203.

C. Confirm completion for silent setups. When ChatSetup.doRun takes DefaultSetup from a user gesture and completes successfully, show a brief confirmation (e.g. INotificationService) so the click isn't perceived as dead. chatSetupRunner.ts:165-182.

D. (Optional) Guard the singleton. Consider whether a queued/refused second click is preferable to silently returning a stale pendingRun. chatSetupRunner.ts:86-88.

Test gap

chat/test/browser/widget/input/chatModelPicker.test.ts:326-333 only asserts that the item's run callback invokes onRequestSetup — it does not exercise the downstream triggerSetup → strategy → controller behavior. The bug lives entirely in that un‑covered downstream, which is why it shipped green. Add a test that, for a Free/Pro entitlement, the triggered flow shows a dialog or otherwise produces visible feedback.

[rwoll]

@dmitrivMS - unfortunately, I'm not around today to fix it (and have not verified the Agent's investigation yet). :/ I messed up here and this all should likely have been behind an experimentation flag. Though, I still cannot reproduce. Due to all the folks touching the model picker in the past week, a clean revert is not possible.

[vs-code-engineering]

We closed this issue because it seems to be about coursework or grading. This issue tracker is for issues about VS Code itself. For coursework-related issues, or issues related to your course's specific VS Code setup, please consider engaging directly with your course instructor.

Happy Coding!