feat: distinct sign-in error when Amazon Q Developer access is blocked

[ashishrp-aws]

Problem

Amazon Q Developer no longer accepts new Builder ID customers. Those users can sign in successfully, then find Q silently non-functional: chat returns the service's rejection as if it were a chat reply, and nothing explains what happened or offers a way out.

What the user sees now

Sign-in succeeds (it is OIDC and never gated). Within a couple of seconds the block is reported, the user is signed out, and the login view shows the service's own message — including a clickable link to kiro.dev — with a single Go back that returns them to sign-in so they can try a different account.

Important: the detection approach changed

The first revision of this PR classified the block from ListAvailableProfiles. That cannot work, and the reasons are worth recording because they constrain any client-side approach:

• RTS gates on User-Agent, not on identity alone. The gate applies only to traffic carrying the shared language server's token (AWS-Language-Servers-AWS-CodeWhisperer). The extension's own SDK calls carry a different UA and are allowed unconditionally. Verified against prod with a blocked Builder ID: the extension's own ListFeatureEvaluations succeeds while the language server's identical call is denied, in the same second.
• Profiles are an IdC concept. restoreProfileSelection() only runs behind isValidEnterpriseSsoInUse() (authUtil.ts), so a Builder ID user never reaches that path — and IdC identities are exempt from the gate, so the only identity type that does reach it is never denied.
• The Builder ID error is not distinguishable. ListAvailableProfiles rejects every Builder ID caller with "AWS Builder ID is not supported for this operation" and reason: undefined — identical for healthy and blocked identities.

So the language server is the only component the service ever says "no" to. It now reports the rejection over the existing Notification feature, and this PR reacts to that.

Changes

Area	Change
lsp/qDevAccessBlockedHandler.ts (new)	Listens for aws/window/showNotification, persists the service message, signs the user out. Never throws.
codewhisperer/util/qDevAccessBlocked.ts (new)	Persisted blocked state, so the message survives the sign-out that follows.
authUtil.ts, backend_amazonq.ts	Route a blocked identity to the existing blocked screen; listRegionProfiles short-circuits to the stored message instead of calling an API that cannot succeed.
backend_amazonq.ts	Go back clears the state and fires onActiveConnectionModified.
regionProfileSelector.vue	URLs in the message render as links.
regionProfileManager.ts	Log name and reason on AccessDenied so a misclassification is diagnosable from customer logs.

Two details worth reviewer attention:

Firing onActiveConnectionModified is required, not defensive. Reacting to the block already signs the user out, so by the time Go back runs there is no connection and signout() is skipped — and root.vue only re-evaluates the auth stage on that event. Without firing it, the state is cleared correctly but the screen never changes. This was a real bug found in testing.

The message is rendered as segments, not v-html. It comes from a service response; interpolating it as markup would let that response inject into the login webview. Splitting into text/URL segments keeps Vue's escaping and puts the URL only in href.

Dependency

Requires a language server carrying the server-side reporting: aws/language-servers #2794, #2796, #2797. Older servers send nothing and this code stays dormant, so this is safe to ship ahead of the server rollout.

Testing

• End to end in VS Code against prod RTS with a Builder ID created after the cutoff: block reported, user signed out, message rendered with working link, Go back returns to sign-in.
• Negative case: a healthy identity is unaffected — no message, normal chat.
• 3 unit tests added covering the routing, the verbatim message, and the Go back path (flag cleared, event fired once, state back to LOGIN).
• Full packages/amazonq unit suite: 858 tests, 0 failures, identical to main (832 passing / 26 pending on both), so no regressions and no tests lost.

Not included

The blank-chat-panel webpack regression (esbuild-loader v4 emitting IIFE and breaking libraryTarget: 'this') is a separate, unrelated bug that would ship in 2.5.0. It is deliberately kept out of this PR and will be raised on its own.

[laileni-aws]

nit:

Improved error messaging when signing in with an account that isn't eligible for Amazon Q Developer — users now see a clear eligibility notice instead of a generic profile loading error.

[laileni-aws]

LGTM, but we may need todo a bugbash for this

[ashishrp-aws]

Converting to draft — please don't merge this yet. Testing against prod surfaced a service-side constraint that means this code path cannot fire in production, so merging it would ship dead code.

Why

The rejection this PR classifies comes from QDevPluginAccessGateHandler in AWSVectorConsolasRuntimeService (enforcement live). Two properties of that gate undercut this change:

IdC is exempt.

if (profileIdentity.getProfileIdentityType() != ProfileIdentityType.SONO) {
    // IdC (Enterprise) Q Developer plugin callers are not subject to the cutoff check.
    job.getMetrics().addCount(METRIC_IDC_ALLOWED, true);
    return;
}

Only Builder ID (SONO) identities created on/after 2026-07-25T00:00:00Z are denied, with reason=FEATURE_NOT_SUPPORTED. But this PR hangs its classification off ListAvailableProfiles, which the extension only calls for IdC connections — requireProfileSelection() returns false for Builder ID (authUtil.ts:325-327). So we're looking for the error on the one identity type that never receives it.

The gate only polices language-server traffic. It matches on the user-agent token AWS-Language-Servers-AWS-CodeWhisperer (ClientMetadataUtil.isQDevPluginUserAgent); everything else takes an unconditional-allow early return. The extension's own SDK v2 clients don't carry that token, so extension-side detection isn't possible at all. That's confirmed empirically — for a blocked Builder ID, the extension's ListFeatureEvaluations succeeds while the language server's identical call is denied.

Two other measurements worth recording

• ListAvailableProfiles rejects every Builder ID caller with AccessDeniedException, reason=undefined, message "AWS Builder ID is not supported for this operation." — a request-shape rejection, not the gate, and identical for blocked and healthy identities. The narrow three-part check in this PR correctly declined to misclassify it and fell through to ListQDeveloperProfilesFailed. A looser check would have shown every Builder ID user the not-accepting-new-customers message.
• Sign-in never touches RTS (OIDC /client/register + /token only), so a blocked identity always signs in successfully. The observable symptom today is a blank chat panel, because every subsequent language-server request is denied.

Where it moved

Detection now lives in the language server, where the denial actually arrives: aws/language-servers#2794. It classifies centrally and surfaces the service message over the existing showNotification channel, which is gated on the client-advertised window.notifications capability — so plugins already in the market are unaffected.

Once that ships, the plugin-side work is: consume the notification, sign out, and show the message with a route back to the auth screen.

What carries over from this PR

The reviewed design mostly transfers, which is why I'm drafting rather than closing:

• the narrow classifier (reason must be exactly FEATURE_NOT_SUPPORTED, so TEMPORARILY_SUSPENDED keeps its retry affordance) — reused as-is in #2794
• showing the service message verbatim rather than canned copy, since FEATURE_NOT_SUPPORTED is reused across several RTS gates and only the message says why
• the dedicated screen with a single action instead of Retry/Sign out
• signOutIfConnected() and the reset path

@laileni-aws — flagging since you approved this. Happy to walk through the service-side detail if useful.