Interactive vs. fail-fast default behavior for WinGet (arguments + settings)

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

Today WinGet's default command behavior is fail-fast and power-user-oriented: install / upgrade / uninstall proceed without interactive confirmation, which keeps the CLI fast and predictable for experienced users who know exactly what they want.

That default can be intimidating or surprising for interactive human users who are newer to WinGet — they may want WinGet to explain what it's about to do and confirm before making changes to their system.

This is a parent/tracking issue for making WinGet's interactivity a deliberate, configurable behavior rather than a fixed default, so both audiences are well served:

• Interactive users get a friendlier, confirm-before-acting experience.
• Power users keep today's fast, non-prompting flow (via --disable-interactivity and/or a setting).

Because changing the default would be a breaking change, this is tracked as a candidate for a future 2.0 release (see #2128). It is distinct from #6034 (a full TUI): this issue is about the CLI's default prompt/confirmation behavior and the arguments/settings that govern it, which can land independently of a TUI.

Proposed technical implementation details

Follow WinGet's established argument + setting pattern (each new behavior gets an argument and a setting with a default, plus prefer/require/override semantics, subject to Group Policy):

• A setting to choose the default interaction model (e.g. failFast / interactive), with today's fail-fast behavior remaining the default until any 2.0 flip.
• Arguments to override per-invocation in both directions (an interactive/confirm opt-in and a non-interactive opt-out), composing with the existing --disable-interactivity.
• Consistent confirmation prompts across install / upgrade / uninstall (show what will change; default-Yes on Enter), suppressible for power users.
• Group Policy consideration so IT administrators can enforce or disable interactivity.
• Ensure power-user flows keep working unchanged if the default eventually changes.

Child issues are tracked as sub-issues below.

Related

• #2128
• #6034

Created with GitHub Copilot.

Start with the WinGet CLI entry points and review the existing argument-and-setting pattern, then read related issues #2128 and #6034 and the child issues. Done means the interaction model, per-invocation overrides, confirmation behavior for install/upgrade/uninstall, Group Policy handling, and future fail-fast default change are specified consistently without breaking power-user flows.