[dungdong-aws]

Summary

• Read aws.dev.* overrides from user settings in packaged stable and pre-release builds.
• Declare all developer overrides with VS Code machine scope so workspace and workspace-folder settings are rejected by the platform.
• Read the developer logfile destination from user settings only.
• Clear displayed developer overrides when forceDevMode is disabled.
• Own settings listeners through the Amazon Q extension lifecycle.

Verification

• npm run testCompile -w packages/amazonq
• Changed-file ESLint
• Changed-file Prettier
• git diff --check
• Added scope, packaged-build, logfile, stale-state, and manifest regression coverage.

[github-actions]

• This pull request implements a feat or fix, so it must include a changelog entry (unless the fix is for an unreleased feature). Review the changelog guidelines.
  • Note: beta or "experiment" features that have active users should announce fixes in the changelog.
  • If this is not a feature or fix, use an appropriate type from the title guidelines. For example, telemetry-only changes should use the telemetry type.

[ashishrp-aws]

🤖 AI-assisted review at 5f6748f.

Approving. In a release build this closes the workspace-settings route:

• The gate. It is now _getGlobalValue('forceDevMode') !== true. A workspace forceDevMode: false, or any workspace or folder value, no longer opens it, and an explicit user false keeps it closed.
• Every read uses user scope only. Values come from inspect(key).globalValue, cast with the declared type, and any cast failure falls back to the default. I checked that every consumer goes through DevSettings.get, including getServiceConfig for codewhispererService, amazonqLsp, amazonqWorkspaceLsp and cloudformationLsp, plus endpoints and telemetryEndpoint. Nothing reads aws.dev.* through vscode.workspace.getConfiguration directly, so there's no bypass.
• isDevMode() follows the same rule, because the overridden _isSet and get both read user scope only.
• unset() is in-memory only (it trims trappedSettings), so calling it from a getter doesn't write to settings.
• Tests and CI. The tests cover workspace forceDevMode true or false with workspace endpoints, user true with workspace endpoints, user false, a workspace false alongside user true, and the non-release path. CI is green.

Should fix (follow-up):

• Pre-release builds still honour workspace values. isReleaseVersion() is false for any semver pre-release, including the 99.0.0-dev beta builds (env.ts:39-51). Anyone running a beta or pre-release VSIX is still exposed to the same repo-supplied codewhispererService endpoint. Unless only builds from source should keep workspace overrides, apply the user-only read whenever the build isn't a local dev build, or at least when isBeta() is true.
• Defense in depth: let VS Code enforce the scope. Only aws.dev.amazonqLsp is declared in package.json, with "scope": "machine". The rest (codewhispererService, endpoints, telemetryEndpoint, amazonqWorkspaceLsp, cloudformationLsp, ssoCacheDirectory, …) are undeclared, so VS Code accepts them from any scope and this check is the only guard. Declaring them with "scope": "machine" (or "application") makes VS Code drop workspace values before the extension sees them.

Non-blocking:

• Stale trapped settings. If a user turns forceDevMode off at runtime, getUserOverride returns defaults but leaves earlier entries in trappedSettings. The dev-mode UI keeps listing them until reload. Clearing trappedSettings when the gate is closed would fix that.
• Description. It's empty, which is the right call for a public repo before the advisory. A one-line summary ("aws.dev.* settings are read from user settings only in release builds") would still help.

[dungdong-aws]

Addressed the review follow-ups and changelog automation comment in 6cbc1ce4b:

• Packaged stable and pre-release builds now use user-scoped developer overrides.
• Extension Development Host sessions retain workspace override behavior using ExtensionContext.extensionMode; the ambient webpack variable cannot bypass packaged scope.
• aws.dev.logfile now reads user scope only.
• Disabling forceDevMode clears active state immediately.
• Telemetry settings initialize lazily after extension globals, and the settings listener is owned by the extension lifecycle.
• Added focused regression coverage and a Bug Fix changelog entry.

testCompile, changed-file ESLint, Prettier, and whitespace checks pass. An independent review accepted exact HEAD 6cbc1ce4b1812f2a6a1f18a2f56c0cdcb60d9c91.

[ashishrp-aws]

🤖 AI-assisted re-review at 6cbc1ce, against my review on 5f6748f.

Approving. Both follow-ups are addressed.

• ✅ Pre-release and beta builds are covered. devOverridesAreUserScoped() is isReleaseVersion(true) && !isExtensionDevelopmentHost(), so every packaged build, stable or pre-release, reads aws.dev.* from user settings only.
• ✅ The dev-host exception can't be set by a repo. It uses ExtensionContext.extensionMode === Development, which a workspace can't set, instead of the webpack env heuristic. It also fails closed: before globals are initialised, isExtensionDevelopmentHost() is false, so the scope stays user-only.
• ✅ Stale trapped settings are cleared. That happens on a forceDevMode change, in isDevMode() and in getUserOverride, and a failed cast now unsets its key.
• ✅ New: aws.dev.logfile is also read from user scope only, since a repo could otherwise pick the log destination.
• Lifecycle. DefaultTelemetryClient.config now initialises lazily, so it no longer reads settings before activation, and the DevSettings listener is disposed with the extension.
• CI is green and the changelog entry is added.

Non-blocking:

• Declare the scope in package.json too. These keys still aren't declared with "scope": "machine", so this code remains the only guard. Declaring them lets VS Code drop workspace values as well.
• Double registration. DevSettings.instance is pushed into context.subscriptions in both activateAmazonQCommon and dev/activation.ts, so it's disposed twice. That's harmless if dispose is idempotent, but one owner would be cleaner.

[dungdong-aws]

Addressed the latest review comments in 3f6a7a2bd:

• Declared all 19 aws.dev.* settings in packages/amazonq/package.json with scope: "machine".
• Regenerated settings-amazonq.gen.ts and generalized the manifest test to require every developer key to be declared and machine-scoped.
• Removed the workspace override exception so runtime behavior matches unconditional VS Code manifest enforcement.
• Kept activateAmazonQCommon as the single Amazon Q lifecycle owner and removed the extra subscription entry from core developer activation.

testCompile, changed-file ESLint, Prettier, and whitespace checks pass. Independent review accepted exact HEAD 3f6a7a2bd8f328a725f9ab7182feb7613d2e6139.