Microsoft shipped Windows Package Manager 1.29.280 on June 24, 2026, and tucked inside is an experimental feature that could reshape how enterprises control software delivery: Source Priority. For the first time, administrators can assign a numerical priority to each package source they’ve configured in WinGet, influencing which package gets installed when more than one source claims to offer the same application.

What Actually Changed

Until now, WinGet’s behavior when faced with duplicate package identities across multiple sources was predictable but rigid. If the community winget repository and a private REST source both held a package called Contoso.App, a bare winget install Contoso.App command would result in an ambiguity error—WinGet would refuse to guess and ask you to pick a source with the --source flag.

Version 1.29.280 introduces the sourcePriority experimental feature. It’s disabled by default, and getting it to work requires an explicit opt‑in inside the WinGet settings JSON file. Once enabled, you can attach a priority number to each source you’ve added. Higher numbers mean higher preference, but the feature operates under strict rules that aren’t quite what many admins will assume.

Microsoft’s documentation is clear about the order of operations during a search. When WinGet evaluates which packages to show—or select during an install—it first considers match quality (how well the package name or ID lines up with your query) and the field that actually matched (name, moniker, etc.). Source priority comes last, after those stronger signals. That means a poorly matching entry on a high‑priority source won’t automatically outrank a spot‑on match from the public winget repo.

The more impactful behavior is in installation. If you run winget install <package> and more than one source returns results, but exactly one highest‑priority source returns exactly one result, WinGet will now proceed with that package automatically instead of stopping to ask for disambiguation. This is the narrow—but powerful—scenario where source priority turns into policy: your automation, scripts, and even interactive sessions can silently accept whatever that favored source supplies.

Both the classic WinGet CLI and the PowerShell module exhibit this behavior, so every command path from a developer’s terminal to a CI/CD pipeline is affected.

What It Means for You

Source Priority lands in your toolkit in a deliberately experimental state, and its practical impact depends entirely on your role.

For Everyday Users and Power Users

If you’re a solo user who only works with the default winget and msstore sources, this feature likely won’t change anything for you. There’s no reason to enable an experimental flag that complicates a system that already works. Power users who maintain personal curated sources might find value in giving their own portable‑app repository a slight edge, but the risk of accidentally pulling a stale version is low when you control the entire chain.

For IT Administrators and Enterprise Architects

This is where Source Priority becomes a strategic decision. If your organization runs a private WinGet REST source hosting internal applications—or carefully validated versions of third‑party tools—you now have a mechanism to make that source the default winner when an ambiguity arises. The obvious move is to assign the private source the highest priority and let it dominate. That would mean, for example, that winget install Acme.ERPClient always grabs the corporate‑approved build, even if the community repo also packages a free version of the same tool.

But that “just make it top priority” instinct is exactly what can get you into trouble. Here’s what Microsoft’s implementation actually does: it gives you a scalpel, not a sledgehammer. Because match quality outranks priority, a typo in your private source’s package identifier could still cause WinGet to select the public version despite your priority settings. And because the automatic‑selection rule only fires when exactly one highest‑priority source returns exactly one result, an over‑broad priority assignment can lead to equally ambiguous situations where WinGet still throws its hands up, leaving your scripts stranded.

For Developers and DevOps Engineers

If you’re maintaining build scripts or infrastructure‑as‑code that relies on WinGet, Source Priority offers a tempting shortcut: avoid writing per‑command --source parameters and let the priority order handle it. The danger is that your pipeline becomes silently dependent on whatever packages happen to exist in the high‑priority repo on any given day. A stale or misnamed package will either be installed in error or, more likely, break the “exactly one result” condition and cause a blocking prompt in a headless session. Neither outcome is acceptable in a deployment pipeline.

How We Got Here

WinGet’s initial 1.0 release in May 2021 came with two built‑in sources: winget (the community repository of manifest‑based packages) and msstore (the Microsoft Store). Support for third‑party REST sources arrived later, opening the door for enterprises to publish internal software catalogs. The trade‑off has always been that overlapping namespaces were inevitable. A company that builds an internal tool called “Widget” has no power to prevent someone else from publishing an unrelated “Widget” on the public repository.

Until now, the only reliable way to resolve conflicts was to be explicit: always use --source or specify a full package ID in scripts. That’s a best practice anyway, but human nature and the conventions of IT automation often push teams toward the simplest possible command. Source Priority is Microsoft’s acknowledgment that organizations want a declarative policy layer, not just a behavioral workaround.

The feature appears in the same release that updates several other experimental areas (direct MSI installation, resume support, fonts), suggesting that WinGet’s roadmap is actively targeting enterprise governance scenarios. Notably, the priority mechanism is implemented purely client‑side: WinGet itself picks the winner based on the priority numbers you configure. There’s no server‑side negotiation, no changes to the repository protocol.

What to Do Now

You’re not required to act. sourcePriority is off by default and will stay that way until you enable it. If you’re evaluating whether to turn it on, follow a deliberate, phased approach.

Step 1: Understand Your Current State

Before touching any settings, run representative searches and installs against all sources your organization uses. For example:

winget search Widget
winget install Widget --accept-source-agreements --verbose

Record which queries currently trigger disambiguation errors. These are the exact spots where Source Priority might later change behavior.

Step 2: Enable the Experimental Feature

Edit your WinGet settings file (launched with winget settings). Add the following under the experimentalFeatures node:

{
  "experimentalFeatures": {
    "sourcePriority": true
  }
}

Save the file and restart your terminal session. There’s no separate command to “activate” the feature; it takes effect immediately for the user profile that owns the settings file.

Step 3: Assign Priorities Based on Package Ownership, Not Catalog Size

The settings schema allows you to assign a numeric priority to each source. Microsoft doesn’t prescribe a specific range, but common convention is to use whole numbers where a higher value means higher preference. For example:

  • Assign 10 to a private source that contains packages your organization officially owns and maintains.
  • Keep the default winget source at 0 (or a lower number) so it remains a fallback for everything else.

Do not blindly assign the highest number to your private source if that catalog is simply a curated copy of third‑party software. The moment you assume responsibility for priority, you also assume responsibility for keeping every package in that source current, correctly identified, and version‑compatible with your automation.

Step 4: Test the Selection Rule, Not Just the Sort Order

Many admins will enable Source Priority, run winget search for a few packages, and nod approvingly when their private source appears first. That’s misleading. The feature’s real power—and danger—is in the automatic installation behavior. You must test with actual install commands that previously caused disambiguation. Use --verbose to see exactly which source WinGet selected:

winget install Widget --verbose

If the install proceeds without prompting, check the source identifier in the logs. If you expected your private source to win but the public one did, your priority numbers or the “exactly one result” rule didn’t work the way you thought.

Step 5: Update Automation Scripts Proactively

For any script that currently relies on winget install <package> and a private source, now is the time to lock in source selection explicitly. Even with Source Priority enabled, the safest command for a CI/CD pipeline remains:

winget install Widget --source my-org-repo --exact

Treat priority as a last‑resort fallback. If your deployment script absolutely requires the organization’s build, say so in the command itself. That way, a future misconfiguration or removal of the private source won’t silently fall through to an uncontrolled public package.

Step 6: Establish a Rollback Plan

Because sourcePriority is experimental, Microsoft can change its behavior—or even remove it—in a future WinGet release. Any organization that comes to depend on it should document exactly what settings were applied and how to revert to source‑explicit commands. At minimum, keep a copy of the settings file before and after enabling the feature, and tag a reference build in your automation environment that works without it.

Outlook

Microsoft hasn’t announced when—or if—Source Priority will graduate from experimental status. The careful language in the documentation (“source priority is the lowest field currently”) suggests the ranking algorithm may evolve, possibly introducing more nuanced weighting or admin‑defined override rules. Early‑adopter feedback will likely drive that conversation.

In the meantime, the feature is best approached as a pilot. Use it in controlled environments, not as a universal policy for thousands of endpoints. When it works as intended, it will save keystrokes and reduce script complexity for the narrow set of packages your organization truly owns. When it doesn’t, the fallout will be limited to the scope of your experiment—provided you’ve kept the public sources enabled and your automation explicit. That’s the disciplined way to put a double‑edged tool to work.