* Re-connecting should be part of DCP request retry

* Simplify implementation

* Additional test

* Update patch version

* Improve comment

* Test improvements

Make sure files used by tests are created in isolated location and deleted no matter test outcome

* Optimizing the read for the kubeconfig file

#18093)

* Use build artifact downloader for npm summaries

The release pipeline consumes npm validation summaries from source builds that published them as build/container artifacts. Download them with DownloadBuildArtifacts instead of the pipeline artifact shortcut so existing source builds can be released without re-spinning.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Fix npm preflight success exit code

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Allow either required npm publish owner

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Improve npm CLI package metadata

* Remove npm README launcher implementation detail

* Relax npm ESRP approver validation

* Require npm ESRP publish aliases

* Address npm release validation review feedback

* Simplify npm publish skip parameters

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Fix CLI E2E package version selection

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Use explicit package version without prerelease flag

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Match exact local hive package files

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Handle CLI update prompt in channel E2E

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Wait past CLI update prompt in channel E2E

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address npm release review feedback

- Extract npm package READMEs into separate template files and render them
  via a shared Expand-Template helper instead of inline here-strings.
- Move the npm ESRP alias validation into eng/scripts/validate-npm-release-aliases.ps1
  (dot-sourceable) with executable unit tests covering empty/whitespace owners,
  multiple approvers, missing required owner, owner/approver overlap, non-Microsoft
  email rejection, @microsoft.com stripping, and effective-set emission. The release
  job runs with checkout: none, so the helpers stay mirrored inline and a test keeps
  the two copies in sync.
- Forward NpmPublishOwners/NpmPublishApprovers to the validation step via env: so
  operator-supplied values are treated as data, not interpolated into the inline script.
- Give NpmPublishOwners/NpmPublishApprovers/NpmRegistryPropagationDelayMinutes working
  defaults and mark them [Advanced] so an unattended queue submission passes validation.
- Replace pack-script source-text assertions with tests that run the script across all
  supported RIDs and assert the generated package.json, package map, and READMEs.
- Clarify the local-hive vs --prerelease comment in KubernetesDeployTestHelpers.
- Update the npm-cli-package spec to describe the new parameter defaults and validation script.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Fix npm CLI README markdown lint

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Harden npm release alias validation

Reject unsafe alias values before emitting Azure Pipelines logging commands and keep the inline release-pipeline validation body covered by the script sync test. Also clarify npm self-update README wording.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Fix npm release pipeline env expansion

Quote queue-time npm release alias parameters when forwarding them through the validation step environment so Azure Pipelines treats the values as strings during release-job expansion.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Avoid object expressions in release pipeline scripts

Compute installer-only logging inside PowerShell instead of embedding a template function result in the inline script scalar, which Azure Pipelines reports as an Object-to-String conversion error at powershell: |.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Use standard MicroBuild release job context

Remove the unsupported templateContext.mb.publish.feedSource object from ReleaseJob; dnceng release-job expansion reports it as an Object-to-String conversion failure at the first powershell step.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Download release artifacts explicitly

Avoid passing current-pipeline artifact objects through ReleaseJob templateContext.inputs; download the prepared artifacts explicitly at the start of ReleaseJob to bypass dnceng release-job object conversion during YAML expansion.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Avoid wildcard template expression in release script

Remove the literal ${{ parameters.* }} text from an inline PowerShell comment because Azure Pipelines expands template expressions inside block scalars and treats the wildcard as the parameters object.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Jose Perez Rodriguez <joperezr@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… MCP tools (#18150)

* Filter resources with resource.excludeFromMcp from CLI MCP tools

Resources marked with the resource.excludeFromMcp property are now
excluded from all MCP tool results:
- ListResourcesTool filters them from resource listings
- ListConsoleLogsTool and ExecuteResourceCommandTool reject requests
  targeting excluded resources
- ListStructuredLogsTool, ListTracesTool, and ListTraceStructuredLogsTool
  filter out telemetry from excluded resources
- McpResourceToolRefreshService skips excluded resources

Added McpToolHelpers with IsExcludedFromMcp, CheckResourceExcludedAsync,
GetExcludedResourceNamesAsync, and GetResourceNotAvailableMessage helpers.

Includes comprehensive unit tests covering all filtering scenarios.

* Add ListTraceStructuredLogsTool exclusion tests and E2E test

- Add two tests for ListTraceStructuredLogsTool filtering:
  - FiltersExcludedResourceLogs: verifies excluded resource logs are
    removed from trace-scoped structured log results
  - ReturnsAllLogs_WhenNoResourcesExcluded: verifies no filtering when
    no resources are excluded
- Add doesNotContainMarker parameter to CallAgentMcpToolAsync helper
- Add AgentMcpExcludeFromMcpTests E2E test that verifies list_resources
  excludes resources marked with ExcludeFromMcp()

* Use quoted markers in E2E test for precise JSON matching

* Avoid redundant connection lookup in exclusion checks

Add overloads of CheckResourceExcludedAsync and GetExcludedResourceNamesAsync
that accept IAppHostAuxiliaryBackchannel directly. Update ListConsoleLogsTool
and ExecuteResourceCommandTool to use the connection they already obtained,
eliminating a redundant GetSelectedConnectionAsync + GetResourceSnapshotsAsync
call per request.

* Use StringComparers.ResourceName and extract CreateExcludedResult helper

* Fix AgentMcpExcludeFromMcp E2E test: disable Redis cache

The test was timing out because the Redis container's health check
never passed in the Docker-in-Docker CI environment, causing
webfrontend (which has WaitFor(cache)) to stay stuck in Waiting state.

Redis is irrelevant to this test — it only verifies ExcludeFromMcp()
filtering. Disabling Redis removes the container dependency.

---------

Co-authored-by: James Newton-King <james@newtonking.com>

…t-cli specifically (#18240)

* Add coding agent telemetry detection

Detect known coding agents from environment variables and include the detected agent name on Aspire CLI main telemetry.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Update src/Aspire.Cli/Telemetry/CodingAgentDetector.cs

* Report copilot-cli specifically & update tests to work in test explorer

* Enhance CodingAgentDetector to support GitHub Copilot CLI and VS Code agents; update tests for new detection logic

---------

Co-authored-by: Damian Edwards <damian@damianedwards.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The playwrightCliVersion configuration value is forwarded to npm as the
package version specifier. Previously any non-empty string would be
passed through, so a typo or unsupported shape (a range, an npm
dist-tag like 'latest', a v-prefixed version, etc.) would surface as a
generic 'failed to resolve' error from npm.

Validate the override with SemVersion.TryParse using SemVersionStyles.Strict
and fail fast with a clear message that names the configuration key and
the offending value when it is not a valid SemVer 2.0 version.

Co-authored-by: Mitch Denny <mitchell.denny@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…903 (#18204)

* Bump StreamJsonRpc to 2.25.25 to clear MessagePack NU1903

The aspire-starter template was emitting NU1903 for transitive
MessagePack 2.5.192 (GHSA-hv8m-jj95-wg3x / CVE-2026-48109) because
the shared StreamJsonRpc 2.22.23 dependency pulled it in. Updating
StreamJsonRpc to 2.25.25 brings MessagePack 2.5.198, outside the
advisory's vulnerable range.

The advisory affects only MessagePack's LZ4 decompression path. We
do not use MessagePackFormatter anywhere - all StreamJsonRpc sites
use SystemTextJsonFormatter - and our JSON-RPC transports are local
UDS under the user's home directory, so the underlying vulnerability
was not reachable. This change is warning hygiene.

Fixes #18153

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Pin MessagePack to 2.5.302 to fully clear GHSA-hv8m-jj95-wg3x

StreamJsonRpc 2.25.25 still declares a transitive dep on
MessagePack 2.5.198, which is inside the advisory's vulnerable
range (< 2.5.302). Add a direct PackageReference on MessagePack
to Aspire.Hosting so consumers (including generated AppHosts from
'aspire new aspire-starter') restore the patched version, and
NU1903 is no longer emitted.

This can be removed once StreamJsonRpc ships a release that
depends on MessagePack >= 2.5.302.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Revert StreamJsonRpc bump; keep MessagePack 2.5.302 pin

StreamJsonRpc 2.25.25 ships analyzers built against Roslyn 4.14, which
breaks template tests that build generated AppHosts with the .NET 8 SDK
(CSC error CS9057). The MessagePack 2.5.302 direct pin in Aspire.Hosting
already overrides StreamJsonRpc 2.22.23's transitive MessagePack 2.5.192
in consumer projects, so the GHSA-hv8m-jj95-wg3x warning is silenced
without needing the StreamJsonRpc bump.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Bump StreamJsonRpc to 2.25.28 and drop MessagePack pin

StreamJsonRpc 2.25.28 brings MessagePack 2.5.302 transitively, which is
above the GHSA-hv8m-jj95-wg3x / CVE-2026-48109 vulnerable range. This
lets us drop the direct MessagePack PackageReference (and PackageVersion)
we added earlier as a workaround.

StreamJsonRpc 2.25.x ships an analyzer built against Roslyn 4.14, which
is newer than the Roslyn 4.11 in the .NET 8 SDK used by template tests
to build generated AppHost projects (would trigger CSC error CS9057). We
don't use the StreamJsonRpc analyzers anywhere in this assembly, so
ExcludeAssets="analyzers" skips them. NuGet bakes the exclusion into
the Aspire.Hosting nuspec so downstream consumers (AppHost projects)
also skip the analyzer transitively.

See microsoft/vs-streamjsonrpc#1459 for the upstream MessagePack bump.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Strip StreamJsonRpc analyzer from consumer AppHost builds

ExcludeAssets in Aspire.Hosting alone is not enough: the .NET 8 SDK
discovers analyzer DLLs in the NuGet cache by convention regardless of
the project.assets.json exclude flags, and StreamJsonRpc.Analyzers.dll
(Roslyn 4.14) fails to load under SDK 8's Roslyn 4.11 with CS9057.

Add a target in Aspire.Hosting.AppHost.targets that runs before
CoreCompile and removes any Analyzer item whose path contains
'StreamJsonRpc.Analyzers'. Aspire doesn't depend on any of the
StreamJsonRpc analyzer diagnostics, so dropping them is safe.

Verified locally: building a net8.0 AppHost with the .NET 8 SDK
(Roslyn 4.11) no longer hits CS9057.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Move StreamJsonRpc analyzer strip to Aspire.Hosting buildTransitive

The Aspire.Hosting.AppHost targets file only reaches direct AppHost
consumers — but Aspire.Hosting.Testing also pulls StreamJsonRpc in
transitively, and the test project (.aspire_xunitTests.csproj) hit the
same CS9057 under .NET 8 SDK. Move the analyzer-strip target into
Aspire.Hosting's buildTransitive/Aspire.Hosting.targets so every
consumer of Aspire.Hosting (AppHost projects, test projects, etc.)
automatically drops the StreamJsonRpc analyzer.

Verified locally: a net8.0 test project that references
Aspire.Hosting.Testing builds cleanly under the .NET 8 SDK.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Simplify StreamJsonRpc analyzer-strip condition using %(Filename)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Bump StreamJsonRpc to 2.25.29; drop analyzer-strip workaround

StreamJsonRpc 2.25.29 ships analyzers compiled against an older Roslyn
that is compatible with the .NET 8 SDK (vs-streamjsonrpc#1463 / #1399),
so the buildTransitive analyzer-strip target and the ExcludeAssets flag
on the PackageReference are no longer needed.

Mirrors the final state of #18155 on main.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Mitch Denny <midenn@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The npm ESRP publish validation previously allowed multiple owner aliases
as long as at least one was a required release owner. Restrict owners to a
single alias (matching the existing single-approver rule) so ownership of
the @microsoft/aspire-cli package maps to one accountable alias.

- Add Assert-SingleNpmReleaseAlias for owners before the required-owner
  check, mirrored in both validate-npm-release-aliases.ps1 and the inline
  helpers in release-publish-nuget.yml.
- Change NpmPublishOwners default from 'joperezr,ankj' to 'joperezr' (the
  old multi-owner default would now fail validation) and update the param
  displayName/spec doc to describe the single-owner rule.
- Update Infrastructure.Tests to cover multi-owner rejection and the new
  default.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…tandalone dashboard (#18221)

* Make npm package README TypeScript-only and document standalone dashboard

Port of #18220 to release/13.4.

- Remove the C# AppHost example so the npm README is TypeScript-only.
- Refresh the TypeScript example to the current ts-starter template
  (apphost.mts importing ./.aspire/modules/aspire.mjs), fixing the stale
  apphost.ts / aspire.js references that no longer match the template.
- Add a Postgres + Redis backing-services example with an `aspire add`
  note for the postgresql and redis integrations.
- Add a Standalone dashboard section documenting `aspire dashboard run`.
- Update NpmCliPackageTests to assert the TypeScript-only README content.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Restore Install heading dropped from npm README

Code review found the install instructions were orphaned under the
'Add backing services' subsection after the C# example removal. Restore
the '## Install' heading so install steps render as their own section.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>