`aspire add` on polyglot AppHosts pinned to a non-default channel cannot offer integrations outside that channel (CommunityToolkit, AWS, ClickHouse unreachable)

[radical]

What's broken

When a polyglot AppHost (apphost.ts / .py / .go / .java / .rs)
has aspire.config.json#channel pinning a non-default channel,
aspire add / aspire integration list / aspire integration search /
MCP list-integrations return only the integrations available
through that one channel. Every integration the user could otherwise add
via their ambient nuget.config (Implicit channel) — including
CommunityToolkit.Aspire.Hosting.*, Aspire.Hosting.AWS,
Aspire.Hosting.ClickHouse, Aspire.Hosting.Elasticsearch, etc. —
becomes invisible.

The user has no in-CLI way to see or add these packages without first
manually editing aspire.config.json to remove the channel pin.

Repro

Setup a PR-acquired install:

./eng/scripts/get-aspire-cli-pr.sh 17105 \
    --install-path /tmp/aspire-issue-val --skip-extension --skip-path
CLI=/tmp/aspire-issue-val/dogfood/pr-17105/bin/aspire

# Polyglot project pinned to the PR channel
mkdir -p /tmp/aspire-issue-val/ts-pinned
cat > /tmp/aspire-issue-val/ts-pinned/apphost.ts <<'EOF'
// stub
EOF
cat > /tmp/aspire-issue-val/ts-pinned/aspire.config.json <<'EOF'
{ "channel": "pr-17105" }
EOF

# Same project shape, no pin
mkdir -p /tmp/aspire-issue-val/ts-unpinned
cat > /tmp/aspire-issue-val/ts-unpinned/apphost.ts <<'EOF'
// stub
EOF

# How many CommunityToolkit / AWS / ClickHouse integrations does each see?
for d in ts-pinned ts-unpinned; do
  echo "=== $d ==="
  $CLI integration list --apphost /tmp/aspire-issue-val/$d/apphost.ts --format json \
    | jq '{
        total: length,
        communityToolkit: [.[] | select(.package | startswith("CommunityToolkit."))] | length,
        aws: ([.[] | select(.package == "Aspire.Hosting.AWS")] | length > 0),
        clickhouse: ([.[] | select(.package == "Aspire.Hosting.ClickHouse")] | length > 0)
      }'
done

Expected

aspire add should show the union of:

• Every integration reachable through the user's ambient nuget.config
  (Implicit channel) — so CommunityToolkit / AWS / ClickHouse / etc.
  remain browseable.
• Every integration exclusive to the pinned channel (e.g. PR-only
  additions not yet on nuget.org).

For any package id that exists in both, the pinned channel's version
should win (so dogfooders see the PR version, not the stable version).
That gives the dogfooder the right version for shared ids without
artificially narrowing what's browseable.

Actual

=== ts-pinned ===
{ "total": 58, "communityToolkit": 0, "aws": false, "clickhouse": false }

=== ts-unpinned ===
{ "total": 118, "communityToolkit": 51, "aws": true, "clickhouse": true }

The pin removes 60 integrations the user could otherwise add — the
entire CommunityToolkit catalog, plus standalone integrations like AWS,
ClickHouse, Elasticsearch.

Reproduces on

• PR feat(cli): aspire doctor lists every Aspire CLI install on the machine #17105 install (13.4.0-pr.17105.g93e48e16): pinned polyglot
  returns 58 rows / 0 CommunityToolkit; unpinned returns 118 rows / 51
  CommunityToolkit.
• Daily/dev install (13.4.0-preview.1.26269.7, installed via
  https://aka.ms/aspire/get/install.sh --quality dev): polyglot pinned
  to "staging" returns 0 rows total (staging synthesis refuses on
  daily-identity CLIs, so the single-channel filter narrows the channel
  set to nothing); unpinned returns 128 rows / 51 CommunityToolkit /
  AWS present. Even more dramatic than the PR-install case.

Why

src/Aspire.Cli/Commands/IntegrationPackageSearchService.cs:28-31:

if (!string.IsNullOrEmpty(configuredChannel))
{
    allChannels = allChannels.Where(c =>
        string.Equals(c.Name, configuredChannel, StringComparison.OrdinalIgnoreCase));
}

When configuredChannel is set (polyglot path), the channel set is
filtered down to exactly one channel by name. The Implicit channel
(name "default") is dropped because it never matches a pr-<N> /
local / staging pin.

The fix needs to keep Implicit in the channel set when a non-default
pin is configured, then rely on dedup to decide which version wins for
shared ids. That keeps off-channel discovery intact without
compromising the pin's authority over shared-id versions.

Scope

Affects:

• aspire add, aspire integration list, aspire integration search,
  MCP list-integrations — all only for polyglot AppHosts with a
  non-default aspire.config.json#channel.

Does not affect:

• C# AppHosts (they have the inverse problem — see aspire add picker displays wrong version for C# AppHosts pinned to a non-default channel (pin ignored, installed version differs from displayed) #17294).
• Polyglot AppHosts with no channel pin (Implicit-only).
• Restore-time resolution (the polyglot guest restore path uses
  aspire.config.json differently from aspire add's picker fan-out).

Possible directions

1. Always include Implicit alongside the configured channel. Dedup
   then layers them naturally: the configured channel wins shared ids
   (so the PR / staging version is displayed); Implicit fills in
   everything the configured channel doesn't have.
2. Make the pin scope explicit — keep the single-channel narrowing
   but add a flag (aspire add --all-channels,
   aspire integration list --include-default) for users who want to
   browse the broader catalog without unpinning.

Option 1 mirrors how dotnet add package itself works: a pinned source
in packageSourceMapping doesn't preclude other sources from
contributing.

Notes

Related to #17225 (which channel the scaffolder writes into a new
aspire.config.json) and #17292 (filter alignment shipping with
PR #17105). This issue is about what the picker reaches for an
already-pinned polyglot project.

Counterpart: #17294 — C# AppHosts have the opposite problem
(the pin is ignored entirely, so the picker shows everything but
displays stable versions for shared ids).

[joperezr]

🤖 Aspire triage pass — 2026-05-20 03:39 UTC

Area: area-cli, area-integrations
Kind: bug
Repro: yes-minimal — see the "Repro" section of the issue body (script reproducing on both PR #17105 install and daily/dev build)
Affected version(s): 13.4.0-pr.17105.g93e48e16, 13.4.0-preview.1.26269.7 (in-development 13.4; not present in shipped 13.3.x)
Severity: S3 — polyglot AppHosts pinned to a non-default channel cannot discover off-channel integrations (CommunityToolkit / AWS / ClickHouse / Elasticsearch); workaround is to remove the pin from aspire.config.json

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: bug is only observable in in-flight 13.4 preview/PR builds (not shipped 13.3.x), has a clean repro with concrete counts (58 vs 118 integrations), cites the exact code path in src/Aspire.Cli/Commands/IntegrationPackageSearchService.cs, and is the counterpart of #17294 in the same channel-pinning family.

Suggested owner(s): @JamesNK (score: dominant area-cli contributor over the last 90 days — merged 70+ PRs in area-cli, including very recent ones #17260, #17251, #17231, #17198), backup @mitchdenny (recent area-cli merges #15423, #15075, #14568)
Evidence:

• JamesNK has merged the overwhelming majority of area-cli PRs in the last 90 days (e.g. Move InitCommand hardcoded strings to resource file for localization #17260, Improve ConsoleCancellationManager with process termination timeout #17251, Route error-context DisplayMessage calls to stderr in BaseCommand #17231, Use grid layout in DisplayMessage/DisplayError for better text wrapping #17198, Fix flaky NewCommandChannelResolutionTests by isolating home directory #17180, Fix CLI cancellation disposal race on shutdown #17179, CLI: Print app host CLI log path when connected to a running app host #17168, Improve version log messages in CLI, AppHost and dashboard #17163, Handle canceled backchannel streams #17114, Refactor CLI commands to return CommandResult and centralize cancellation handling #17005)
• mitchdenny has merged area-cli PRs Fix config discovery to search from apphost directory and add aspire.config.json to .NET templates #15423, Remove mature feature flags that no longer need toggles #15075, Fix CopilotCliRunner version parsing for 'GitHub Copilot CLI X.X.X' format #14568, Fix TryGetResourceToolMap cache miss causing perpetual tools/list refresh loop #14539
• Issue author @radical is excluded as the reporter
• CODEOWNERS not consulted (the cited file lives under src/Aspire.Cli/, broadly owned by the CLI team)

Confidence: medium
Needs human?: no — but a human should confirm whether this should ride alongside the fix for #17294 (same family) and whether PR #17105 already addresses one of the two.

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.

[davidfowl]

cc @mitchdenny can you look at this?

[radical]

cc @mitchdenny can you look at this?

two PRs in similar areas - #17280 and #17105 . Keep those in mind.