Every day, Windows 11 users fire up Terminal and type a quick command to grab a popular app: winget install vscode. But that shortcut, while convenient, can quietly pull software from a source you didn’t intend — a Microsoft Store version, a community-maintained fork, or even a similarly-named imposter. As the Windows Package Manager (WinGet) continues to grow, its dual-repository design is catching newcomers off guard. The fix, however, is straightforward and takes only a few extra moments: a simple search-inspect-install-verify routine that locks in exactly the package you want.

The Source of the Problem

WinGet doesn’t install software from a single, unified catalog. Instead, it queries multiple configured sources and picks the first match it finds. Out of the box, Windows 11 includes two sources: winget (the community repository) and msstore (the Microsoft Store). A third source, winget-font, exists for fonts but isn’t included in regular searches by default.

When you run winget install appname, WinGet searches across both winget and msstore simultaneously. The result isn’t always predictable — especially when similar package names exist across sources. A query for “python” might return the official CPython release from the community repo, while another machine might get a Microsoft Store variant that carries a different version or publisher metadata. For corporate environments or scripted deployments, that ambiguity isn’t just an annoyance — it’s a potential compliance and security risk.

What It Means for You

Home users: You’re most likely to stumble into a mismatch when installing developer tools or utilities that exist in both catalogs. The consequences range from mild confusion (a different version of VLC than you expected) to genuine frustration (a missing plugin or incompatible configuration). Even seemingly safe apps can surprise you: the Store version of an app might lack certain command-line interfaces, while the community build might bundle extras you don’t need.

IT professionals and power users: If you maintain deployment scripts or Windows setup lists, the risk multiplies. An automated winget install firefox could install the Microsoft Store edition on some boxes and the community edition on others, leading to inconsistent behavior across your fleet. Worse, a malicious actor could potentially upload a similarly named package to the community repo, tricking unvetted scripts into pulling harmful code.

Developers: Your toolchain depends on precise versions and predictable environments. Using bare winget install without pinning a source can break CI/CD pipelines or local development setups when a package’s source shifts unexpectedly after a source update.

How We Got Here

WinGet debuted in 2020 as Microsoft’s answer to third-party package managers like Chocolatey and Scoop. Designed for simplicity, it shipped with the App Installer on modern Windows builds and promoted a familiar one-liner: winget install <app>. The community repository grew rapidly, curated by Microsoft and open-source contributors, while the Microsoft Store provided an official, managed alternative.

But the original design prioritized convenience over explicitness. Early documentation glossed over source selection, and many online tutorials still propagate the unsafe winget install appname pattern. Microsoft’s own learn.microsoft.com pages now emphasize searching and inspecting packages before installing, but the habit has stuck. Meanwhile, the company released a detailed settings schema (accessible at aka.ms/winget-settings.schema.json) that gives users fine-grained control over installer preferences — a tool that can mitigate but not replace manual verification.

The Safer Way: Search, Identify, Inspect, Install, Verify

Instead of gambling on a single command, adopt a quick five-step workflow that ensures every package you install is exactly what you expect.

1. Search with a clear query

Don’t type a guess. Use the full product name and scan the output table:

winget search "Visual Studio Code"

Pay close attention to three columns: Id, Version, and Source. The source tells you which catalog the package came from. If the results are noisy, narrow your search by source:

winget search "Visual Studio Code" --source winget

2. Identify the correct ID and source

Copy the Id and Source for the package you actually want. Don’t assume the first result is best. If the same app appears under both sources, inspect each one before deciding.

3. Inspect the candidate package

Use winget show to pull detailed metadata:

winget show --id Microsoft.VisualStudioCode --source winget

This reveals the publisher, version, installer type, and licensing. For a Microsoft Store candidate, replace the source accordingly:

winget show --id XP9KHM4NQN9P2Q --source msstore

If anything looks off — wrong publisher, unexpected version — go back to step one.

4. Install with explicit ID and source

Lock in your choice by providing both:

winget install --id Microsoft.VisualStudioCode --source winget

The reusable pattern is winget install --id Publisher.Package --source <source>. Don’t skip the --source flag; without it, WinGet might resolve to a different catalog than the one you inspected.

5. Verify the result and launch the app

Run winget list --id Microsoft.VisualStudioCode to confirm the installed package matches. Then open the application normally and check that it’s the edition and version you intended.

Fine-Tuning with WinGet Settings

If you consistently prefer one source or installation scope, you can encode those preferences in WinGet’s JSON settings file — but do so carefully. Open the file with winget settings, then add a preferences block to nudge the installer toward your favored choices:

{
  "$schema": "https://aka.ms/winget-settings.schema.json",
  "installBehavior": {
    "preferences": {
      "scope": "user",
      "architectures": ["x64"]
    }
  }
}

A preference leaves WinGet free to fall back to other options when your first choice isn’t available. In contrast, a requirement will reject any installer that doesn’t match — a strict rule that can break installations. Beginners should rely on the manual workflow first, then add preferences as a safety net.

Building a Bulletproof Setup Script

For repetitive deployments, build your command list one app at a time using the five-step process. Only save a command after you’ve tested it interactively and verified the result. A trusted list might look like:

winget install --id Mozilla.Firefox --source winget
winget install --id Microsoft.VisualStudioCode --source winget
winget install --id 9WZDNCRFJ3TJ --source msstore

Always re-test these commands before running them on a new batch of machines — package IDs can change, and sources can reorganize. Automation gained this way is both fast and reliable, because each line is backed by a known good installation.

When Things Go Wrong

Search returns too many matches: Sharpen your search terms or target a source directly. Never settle for the first line in the table.

A package appears in both msstore and winget: Inspect both with winget show and pick the one that matches your needs. Remember to carry the --source flag through to the install command.

You can’t find a font: Use the dedicated font source:

winget search "font name" --source winget-font

Installation fails: Don’t start adding random switches like --silent or --force. Instead, repeat the search and inspection steps, confirm the error message, and check the vendor’s documentation before trying again.

The Outlook

WinGet’s role in Windows 11 will only expand as more packages join the repository and Microsoft deepens integration with tools like Dev Home and Windows Configuration Designer. Expect future updates to offer clearer source-priority controls and perhaps built-in verification prompts. But for now, the safest path is a human one: take the sixty seconds to inspect what you’re about to install. Your future self — and your fleet of machines — will thank you.