Let agents start and stop AppHosts through VS Code

[Adam Ratzman (adamint)]

Description

Adds two Language Model tools so agents can use VS Code's AppHost lifecycle instead of starting a separate CLI process:

Tool	Reference in chat	What it does
aspire_apphost_start	#aspireStartAppHost	Starts a discovered AppHost in run or debug mode through AppHostLaunchService
aspire_apphost_stop	#aspireStopAppHost	Stops a discovered AppHost by coordinating its Aspire debug session or delegating to aspire stop --apphost

The tools only accept buildable AppHosts returned by the extension's existing discovery service. Unknown selectors return the available knownAppHosts, multi-root workspaces get stable folder qualifiers, and confirmation text is built from the resolved target rather than echoed model input.

Before starting, the extension checks its tracked Aspire sessions and a one-shot aspire ps result. Start reports an AppHost started outside this editor instead of launching a duplicate. Stop coordinates a matching Aspire debug session when this editor owns one; otherwise it delegates to aspire stop --apphost for the same discovered AppHost. Lifecycle operations are serialized per AppHost across tool and editor launches.

Both tools require a trusted workspace and user confirmation.

Fixes #18324

Evidence

Start confirmation

Stop confirmation

• Focused lifecycle tests: 19 passing
• Full extension unit suite: 1472 passing, 4 pending
• Extension compile and lint pass

Checklist

• Feature is complete
• Unit tests cover the changed behavior
• No public extension API was added

The model-provided selector is never used as a filesystem target. It is only compared with selectors generated from discovered AppHosts. Stop coordinates a matching tracked debug session when present; otherwise, for a matching running AppHost returned by aspire ps, it delegates to aspire stop --apphost with the resolved discovered path.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19134

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19134"

[Copilot]

Pull request overview

Adds VS Code language-model tools for safely starting and stopping workspace AppHosts through editor-owned debug sessions.

Changes:

• Adds start/stop tools with validation, confirmation, ownership checks, and lifecycle locking.
• Extends AppHost session tracking and detection.
• Adds localization, unit tests, and end-to-end coverage.

Show a summary per file

File	Description
extension/src/views/AppHostDataRepository.ts	Adds cancellable, resource-free AppHost queries.
extension/src/utils/appHostLanguage.ts	Adds source-file AppHost validation.
extension/src/types/extensionApi.ts	Adds E2E tool-control commands.
extension/src/testing/e2eStateFileBridge.ts	Exposes tool preparation and invocation to E2E tests.
extension/src/test/testRunSessionManager.test.ts	Verifies test-session classification.
extension/src/test/appHostLifecycleTools.test.ts	Tests lifecycle tools and security boundaries.
extension/src/test/appHostLaunchService.test.ts	Tests locking and session identity.
extension/src/test/appHostLanguage.test.ts	Tests source classification.
extension/src/test-e2e/helpers/vscode.ts	Adds modal-dialog automation.
extension/src/test-e2e/helpers/extester.ts	Exposes Extester modal APIs.
extension/src/test-e2e/appHostLifecycleTools.e2e.test.ts	Exercises real start/stop tool flows.
extension/src/services/AppHostLaunchService.ts	Adds shared lifecycle locking and ownership providers.
extension/src/loc/strings.ts	Adds localized runtime messages.
extension/src/lm/appHostLifecycleTools.ts	Implements the lifecycle tools.
extension/src/extension.ts	Registers and wires the tools.
extension/src/debugger/AspireDebugSession.ts	Tracks operation and resolved AppHost identity.
extension/src/dcp/types.ts	Defines operation kinds.
extension/src/dcp/TestRunSessionManager.ts	Marks leased sessions as tests.
extension/README.md	Documents agent chat tools.
extension/package.nls.json	Adds manifest localization strings.
extension/package.json	Contributes and activates the tools.
extension/loc/xlf/aspire-vscode.xlf	Updates the localization catalog.

Review details

Suppressed comments (2)

extension/src/lm/appHostLifecycleTools.ts:715

• In every multi-root workspace, a relative input produces the fixed “unresolved path” confirmation because this branch only constructs a candidate when there is exactly one folder. resolveTarget, however, probes all workspace folders and will execute the file when exactly one exists. That lets a tool launch an AppHost the user was never shown; prepare should resolve and display a workspace-qualified target, or invocation must reject inputs that could not be identified in the confirmation.

        ? path.isAbsolute(requestedPath)
            ? path.resolve(requestedPath)
            : workspaceFolders.length === 1
                ? path.resolve(workspaceFolders[0].uri.fsPath, requestedPath)
                : undefined

extension/src/services/AppHostLaunchService.ts:184

• This identity comparison is case-sensitive on macOS because getComparisonKey only folds case on Windows. On the default case-insensitive macOS filesystem, differently cased input resolves to the same AppHost file but will not match the editor session or aspire ps result, so duplicate prevention can start a second process. Canonicalize existing paths with realpath or apply the same Darwin comparison policy used by appHostDiscovery.ts:1192-1200.

    isSameAppHostIdentity(left: string | undefined, right: string | undefined): boolean {
        if (!left || !right) {
            return false;
        }

        return isMatchingAppHostPath(path.resolve(left), path.resolve(right));

• Files reviewed: 22/22 changed files
• Comments generated: 5
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (5)

extension/src/lm/appHostLifecycleTools.ts:690

• The confirmation path is lossy: the sanitizer removes valid filename characters above and truncates the remainder here, while invocation still executes the original full path. Two files can therefore produce the same displayed approval target (the bidi/zero-width test already exercises this mismatch). Reject paths that cannot be represented within the bound or escape them losslessly so the confirmed identity exactly matches the executed file.

    return singleLine.length > maxLength ? `${singleLine.slice(0, maxLength)}…` : singleLine;

extension/src/utils/appHostLanguage.ts:259

• These regexes search withoutComments, which preserves all string literals. For example, const note = "from '@aspire/hosting'" plus executable createBuilder()/build().run() markers passes without importing Aspire, so an arbitrary JS/TS file can get through this execution gate. Parse actual import/require syntax rather than matching module-looking text inside arbitrary literals.

    function referencesAspireModule(contents: string): boolean {
        const moduleSpecifiers = [
            ...contents.matchAll(/\bfrom\s*(["'])(?<specifier>[^"']+)\1/g),
            ...contents.matchAll(/\brequire\s*\(\s*(["'])(?<specifier>[^"']+)\1\s*\)/g),
        ];

extension/src/services/AppHostLaunchService.ts:256

• This key collapses every C# project/source target in one directory into the same lock, even though isSameAppHostIdentity treats sibling First.csproj and Second.csproj as distinct and launching state tracks them independently. A long operation on one sibling can make operations on the other time out as busy. Use a canonical per-AppHost identity/alias mapping rather than the directory as the key.

        return isProjectFile(resolvedPath) || isSourceFile(resolvedPath)
            ? `${getComparisonKey(path.dirname(resolvedPath))}${path.sep}`
            : getComparisonKey(resolvedPath);

extension/src/lm/appHostLifecycleTools.ts:372

• The tool contract and manifest require a workspace-relative path, but this branch accepts an absolute path whenever it falls inside a workspace. Reject absolute inputs instead of silently normalizing them to the documented relative form.

        const candidates = path.isAbsolute(requestedPath)
            ? [path.resolve(requestedPath)]
            : workspaceFolders.map(folder => path.resolve(folder.uri.fsPath, requestedPath));

extension/src/utils/appHostLanguage.ts:243

• withoutComments retains raw-string contents, so a multiline raw string with #:sdk Aspire.AppHost.Sdk... at the start of one of its lines satisfies this check even though the file has no SDK directive. Use the view that blanks literals; real directives remain executable text.

        return /^[ \t]*#:sdk[ \t]+Aspire\.AppHost\.Sdk\b/m.test(withoutComments)

• Files reviewed: 22/22 changed files
• Comments generated: 3
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (2)

extension/src/lm/appHostLifecycleTools.ts:330

• If the pre-lock getRunningAppHosts probe throws, control reaches this catch before any editor-owned session or launch exists, yet the result reports ownership: 'editor'. That contradicts the ownership contract, which defines unknown for a failed probe, and can mislead the agent into believing the editor owns a process. Handle ownership-probe failures separately as failed/unknown; the existing test that expects editor for this case should be corrected too.

        catch (error) {
            return this.createErrorResult(aspireAppHostStartToolName, error, preflight.target.relativePath, 'editor', requestedMode, undefined);

extension/src/lm/appHostLifecycleTools.ts:377

• externalOwnershipBeforeLock can be stale after waiting up to 10 seconds for the lifecycle lock. If a terminal starts this AppHost during the wait, the cached none makes the tool return notRunning; if it exits, cached external returns notEditorOwned. Revalidate external ownership after the lock wait, or restructure the flow so the pre-lock probe is only a fast path and never an authoritative result.

                if (owned.sessions.length === 0) {
                    const externalOwnership = externalOwnershipBeforeLock
                        ?? await this.probeExternalOwnershipForStop(current.absolutePath, token);

• Files reviewed: 23/23 changed files
• Comments generated: 2
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (7)

extension/src/utils/appHostIdentity.ts:44

• This key is only lexically normalized, although resolveTarget accepts symlinks whose targets stay in the workspace. A launch through such a symlink and a later call through the canonical path get different keys; because both paths are project files, compareAppHostIdentity also returns different. That permits a duplicate launch and prevents stop from finding the editor-owned session. Canonicalize existing paths with realpathSync.native, falling back to the lexical path only when resolution fails.

export function getAppHostPathComparisonKey(value: string): string {
    const resolved = path.normalize(path.resolve(value));
    return process.platform === 'win32' ? resolved.toLowerCase() : resolved;

extension/src/lm/appHostLifecycleTools.ts:377

• The pre-lock none result can be up to 10 seconds stale by the time this branch runs. If a terminal starts the AppHost while this call waits for the lifecycle lock, this returns notRunning instead of the required notEditorOwned; the inverse race reports an already-exited process as external. As with start, only use a positive pre-lock result as an early exit and re-probe after the lock when the earlier result was negative.

                if (owned.sessions.length === 0) {
                    const externalOwnership = externalOwnershipBeforeLock
                        ?? await this.probeExternalOwnershipForStop(current.absolutePath, token);

extension/src/lm/appHostLifecycleTools.ts:330

• A failure in the pre-lock external-ownership probe lands here even when no editor session exists, but the result is labeled ownership: 'editor'. That contradicts the declared ownership contract (unknown means the probe failed) and can mislead the agent about who owns the process. Distinguish probe failures from failures after an editor-owned launch attempt and return unknown for the former.

This issue also appears on line 375 of the same file.

        catch (error) {
            return this.createErrorResult(aspireAppHostStartToolName, error, preflight.target.relativePath, 'editor', requestedMode, undefined);

extension/src/lm/appHostLifecycleTools.ts:843

• startsWith('..') also rejects valid contained paths whose first component merely begins with two dots, such as ..cache/AppHost.csproj. Those paths are inside the workspace but are reported as outside it. Check for the exact parent component (relative === '..' or a ..${path.sep} prefix) instead.

function isContainedIn(folderPath: string, candidate: string): boolean {
    const relative = path.relative(folderPath, candidate);
    return relative.length > 0 && !relative.startsWith('..') && !path.isAbsolute(relative);
}

extension/src/lm/appHostLifecycleTools.ts:781

• Ampersands also change rendered Markdown through entity decoding. For example, a real path foo©/AppHost.csproj is displayed as foo©/AppHost.csproj, so the confirmation is still not one-to-one with the executed target. Escape & along with the other Markdown metacharacters.

function escapeMarkdown(value: string): string {
    return value.replace(/[\\`*_[\]()<>#+~|!]/g, character => `\\${character}`);

extension/src/utils/appHostLanguage.ts:247

• A UTF-8 BOM is decoded as U+FEFF, so a valid single-file C# AppHost beginning with the normal BOM followed by #:sdk fails this anchored match and is rejected as notAnAppHost. Strip one leading BOM from the executable view before testing the directive.

        return /^[ \t]*#:sdk[ \t]+Aspire\.AppHost\.Sdk\b/m.test(executable)

extension/src/utils/appHostLanguage.ts:218

• This accepts source files by extension, but the current CLI handlers only recognize the exact names apphost.cs, apphost.ts, and apphost.mts (DefaultLanguageDiscovery.cs:25,32 and DotNetAppHostProject.cs:150-157). A marker-complete Other.cs or apphost.js therefore passes this gate, yet the CLI rejects it after VS Code has started the debug session, while the tool can already report started. Restrict targets to filenames supported by the installed CLI (preferably via capabilities) rather than all parser extensions.

export function isSupportedAppHostFileExtension(filePath: string): boolean {
    const extension = extname(filePath).toLowerCase();
    return appHostProjectFileExtensions.includes(extension)
        || appHostCSharpSourceExtensions.includes(extension)
        || appHostJsTsSourceExtensions.includes(extension);

• Files reviewed: 23/23 changed files
• Comments generated: 1
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (5)

extension/src/lm/appHostLifecycleTools.ts:537

• AppHostDiscoveryService.discover() returns candidates of every status, while the existing tree only exposes candidates whose status is buildable (AppHostDataRepository.ts:753-756). As written, an entry such as possibly-unbuildable is included in knownAppHosts and can be selected and launched, contradicting this tool's buildable-only contract. Filter the discovery result here and add a non-buildable-candidate regression test.

        const candidatesByFolder = await Promise.all(workspaceFolders.map(async folder => ({
            folder,
            candidates: await this._dependencies.discoveryService.discover(folder, false, token),
        })));

extension/src/lm/appHostLifecycleTools.ts:560

• Workspace folder names are not guaranteed to be unique. If two roots have the same folder.name and relative AppHost path, this produces identical displayPath values; resolution then returns ambiguousAppHost with duplicate knownAppHosts, leaving no selector that can address either target. Disambiguate duplicate root names with a stable unique qualifier and use it consistently in the schema text, README, confirmation, and tests.

                const displayPath = workspaceFolders.length > 1
                    ? `${folder.name}/${relativePath}`
                    : relativePath;

extension/src/lm/appHostLifecycleTools.ts:868

• This containment check also rejects valid children whose first path segment merely starts with .., such as <workspace>/..services/AppHost.csproj. Check for the parent segment itself (or ..${path.sep}) instead so valid discovered AppHosts are not silently dropped.

    const relative = path.relative(folderPath, candidate);
    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {
        return undefined;

extension/src/lm/appHostLifecycleTools.ts:388

• A failure of the initial aspire ps probe reaches this outer catch before any editor-owned session or controller has been identified, but the result reports controller: 'editor'. That makes the tool's structured response inaccurate; the controller contract already defines unknown for probe failures (and stop uses it correctly). Return unknown here and update the existing probe-failure test accordingly.

This issue also appears in the following locations of the same file:

• line 534
• line 558
• line 866

        catch (error) {
            return this.createErrorResult(aspireAppHostStartToolName, error, preflight.target.relativePath, 'editor', requestedMode, undefined);

extension/src/debugger/AspireDebugConfigurationProvider.ts:146

• The PR description says this intentionally does not add a lifecycle lock or debugger reservation protocol around F5, but this code reserves every external run and can cancel F5 when a lifecycle-owned launch wins the race. The new tests also explicitly enforce that behavior. Update the description if this user-visible F5 arbitration is intended, or remove the reservation path to match the stated scope.

            if (!launchedByExtension && getAspireDebugConfigurationCommand(aspireConfig) === 'run') {
                const claimedPath = telemetryTarget?.path ?? (typeof config.program === 'string' ? config.program : undefined);
                const reservationId = existingExternalReservationId ?? (claimedPath
                    ? this._launchReservation.tryReserveExternalLaunch(claimedPath)
                    : false);

• Files reviewed: 34/34 changed files
• Comments generated: 1
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (3)

extension/src/lm/appHostLifecycleTools.ts:868

• This containment check rejects valid in-workspace paths whose first segment merely begins with .. (for example, /workspace/..hidden/AppHost.csproj produces ..hidden/AppHost.csproj). Such AppHosts are returned by discovery but silently removed from the tool registry, so the documented “discovered AppHosts” contract is incomplete. Only reject the exact parent segment or a ..${path.sep} prefix.

    const relative = path.relative(folderPath, candidate);
    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {
        return undefined;

extension/src/lm/appHostLifecycleTools.ts:387

• An aspire ps failure from either isRunningOutsideEditor call reaches this catch before the extension has identified or acted on an editor-owned session, yet the result reports controller: 'editor'. This contradicts the result contract above, where unknown is specifically reserved for probe failures, and can make an agent treat an externally controlled or indeterminate AppHost as editor-owned. Classify probe/pre-launch failures as unknown (while keeping launch failures classified as editor) and update the corresponding assertion.

        catch (error) {
            return this.createErrorResult(aspireAppHostStartToolName, error, preflight.target.relativePath, 'editor', requestedMode, undefined);

extension/src/lm/appHostLifecycleTools.ts:547

• The discovery service returns candidates of every status, but this loop registers all of them. As a result, selectors for non-buildable candidates are accepted and can reach startDebugging, contrary to the PR’s explicit guarantee that these tools only accept buildable AppHosts (the existing discovery helpers define buildable as status === 'buildable'). Filter candidates before creating tool targets so rejected candidates are not listed in knownAppHosts either.

            for (const candidate of candidates) {
                const relativePath = toContainedPosixRelativePath(folder.uri.fsPath, candidate.path);

• Files reviewed: 34/34 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Ella Hathaway (ellahathaway)]

I reviewed the AppHost lifecycle tools end to end, including target resolution and confirmation, workspace trust, editor/external ownership, F5 reservations, lifecycle locking, debug-session tracking, cancellation/disposal, process termination, localization, and unit/E2E coverage.

I found two concrete issues: one deterministic CI configuration failure and one lifecycle-lock race reintroduced after an earlier fix. I did not find separate nonblocking architectural concerns; the central lifecycle ownership and supporting boundaries are otherwise coherent.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (2)

extension/src/utils/appHostIdentity.ts:13

• apphost.cs can be an independently discovered, buildable single-file AppHost, but this identity model aliases it to the sole .csproj in the directory. When both are valid candidates, starting one is incorrectly deduplicated against the other, and stopping by one selector can terminate the other's editor session. AppHostDiscovery.findCandidateForEditorFile already treats an exact apphost.cs candidate as distinct; this comparison needs equivalent candidate-aware handling rather than inferring identity solely from directory shape.
  extension/src/lm/appHostLifecycleTools.ts:546
• discover() returns all CLI candidates, including possibly-unbuildable entries; the rest of the extension explicitly filters these before offering launch targets. Adding every candidate here lets the tool accept and try to start an AppHost that the PR contract says must be buildable. Filter on candidate.status === 'buildable' before constructing the target.

            for (const candidate of candidates) {

• Files reviewed: 34/34 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (2)

extension/src/lm/appHostLifecycleTools.ts:546

• The discovery service also returns non-buildable candidates, but this loop exposes every candidate as a valid lifecycle target. That contradicts the tool contract and lets an agent attempt to launch an AppHost that discovery explicitly marked unbuildable (and advertises it through knownAppHosts). Filter candidates to status === 'buildable' before adding them.

            for (const candidate of candidates) {

extension/src/lm/appHostLifecycleTools.ts:867

• This containment check also rejects valid in-workspace paths whose first segment merely starts with two dots, such as ..apps/AppHost.csproj. Such a buildable discovered AppHost is silently omitted from both resolution and knownAppHosts; only an exact .. parent segment should be rejected.

    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {

• Files reviewed: 35/35 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (4)

extension/src/lm/appHostLifecycleTools.ts:546

• AppHostDiscoveryService.discover() returns candidates in every status, but this loop exposes all of them as valid tool targets. A candidate reported as unbuildable can therefore appear in knownAppHosts and be passed to launchFromLifecycleOwner, contradicting the buildable-only contract. Filter candidates by status === 'buildable' before creating targets.

            for (const candidate of candidates) {

extension/src/lm/appHostLifecycleTools.ts:867

• This containment check rejects valid children whose first path segment merely starts with .. (for example, <workspace>/..generated/AppHost.csproj). Such a discovered AppHost is omitted and even the selector returned by discovery cannot be used. Only the actual parent segment .. followed by the platform separator should count as escaping the folder.

    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {

extension/src/lm/appHostLifecycleTools.ts:560

• Workspace folder names are not guaranteed to be unique (two roots commonly share the same basename). If both contain the same relative AppHost path, this produces identical displayPath values; resolution then returns ambiguousAppHost with two identical knownAppHosts, leaving no selector that can address either target. The qualifier scheme needs a stable unique fallback for duplicate folder names, with the manifest/README contract updated accordingly.

                const displayPath = workspaceFolders.length > 1
                    ? `${folder.name}/${relativePath}`
                    : relativePath;

extension/src/lm/appHostLifecycleTools.ts:387

• This catch also handles failure of the pre-lock getRunningAppHosts probe, but reports controller: 'editor' even though no editor operation occurred and ownership could not be determined. That contradicts the result contract above, which defines unknown specifically for a failed probe, and can mislead an agent about who controls the AppHost. Distinguish probe/lock failures from failures after the editor launch path has been selected.

        catch (error) {
            return this.createErrorResult(aspireAppHostStartToolName, error, preflight.target.relativePath, 'editor', requestedMode, undefined);

• Files reviewed: 35/35 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (3)

extension/src/lm/appHostLifecycleTools.ts:547

• The lifecycle registry currently accepts every aspire ls candidate, including possibly-unbuildable entries. That lets the tools launch targets the PR contract says must be rejected and that the existing AppHost view excludes. Filter candidates to status === 'buildable' before exposing selectors.

            for (const candidate of candidates) {

extension/src/lm/appHostLifecycleTools.ts:387

• This catch also handles failures from both aspire ps probes, but reports controller: 'editor' even though no editor session was established and the controller could not be determined. That contradicts the result contract's unknown controller and can mislead an agent into treating an external-process probe failure as editor ownership. Catch probe failures separately or carry the established controller into error mapping.

        catch (error) {
            return this.createErrorResult(aspireAppHostStartToolName, error, preflight.target.relativePath, 'editor', requestedMode, undefined);

extension/src/lm/appHostLifecycleTools.ts:867

• This containment check rejects valid in-workspace paths whose first segment merely begins with .. (for example ..tools/AppHost.csproj). Such a buildable discovered AppHost is incorrectly dropped as outside the workspace. Match the parent segment itself, including its separator, instead of any .. prefix.

    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {

• Files reviewed: 36/36 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (2)

extension/src/lm/appHostLifecycleTools.ts:560

• WorkspaceFolder.name is user-configurable and is not guaranteed to be unique. If two roots use the same name and contain the same relative AppHost path, both targets receive the same displayPath; resolution then returns ambiguousAppHost with duplicate knownAppHosts, so neither AppHost has any selector the caller can use. Generate deterministic unique folder qualifiers when names collide.

                const displayPath = workspaceFolders.length > 1
                    ? `${folder.name}/${relativePath}`
                    : relativePath;

extension/src/lm/appHostLifecycleTools.ts:546

• Discovery returns candidates in every status, but this loop exposes all of them as valid tool targets. The Aspire view filters to status === 'buildable', so an agent can currently select and launch a non-buildable candidate even though the tool contract says it accepts only buildable AppHosts. Filter candidates before adding them to targets.

This issue also appears on line 558 of the same file.

            for (const candidate of candidates) {

• Files reviewed: 36/36 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

Review details

Suppressed comments (4)

extension/src/lm/appHostLifecycleTools.ts:111

• In a multi-root workspace, all outcomes return relativePath, which omits the folder qualifier required by the tool input. For example, starting second/AppHost/AppHost.csproj reports appHostPath: "AppHost/AppHost.csproj"; passing that result to the stop tool is then rejected as ambiguous. Return the stable displayPath selector in tool results so outputs can be used as inputs.

    /** Path relative to the containing workspace folder, or empty when the input could not be resolved. */
    appHostPath: string;

extension/src/lm/appHostLifecycleTools.ts:547

• Discovery returns candidates such as possibly-unbuildable, but this loop registers every status as an executable target. That contradicts the tool contract that only buildable AppHosts are accepted and can make the agent launch a candidate the existing workspace selection logic deliberately excludes. Filter to status === 'buildable' before adding the target.

            for (const candidate of candidates) {
                const relativePath = toContainedPosixRelativePath(folder.uri.fsPath, candidate.path);

extension/src/lm/appHostLifecycleTools.ts:869

• This containment test rejects valid in-workspace names whose first segment merely begins with .. (for example ..tools/AppHost.csproj). path.relative() only denotes a parent traversal when the result is exactly .. or starts with .. plus the platform separator.

    const relative = path.relative(folderPath, candidate);
    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {
        return undefined;

extension/loc/xlf/aspire-vscode.xlf:21

• This is a generated localization export. The extension localization guidance explicitly says not to edit or commit *.xlf output because source strings belong in package.nls.json/src/loc/strings.ts and translations are handled by the localization workflow. Revert all additions in this generated file.

    <trans-unit id="aspire-vscode.strings.appHostLifecycleBusy">
      <source xml:lang="en">Another start or stop operation for this Aspire AppHost is still in progress. Wait for it to finish and try again.</source>
    </trans-unit>

• Files reviewed: 36/36 changed files
• Comments generated: 1
• Review effort level: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Review details

Suppressed comments (3)

extension/src/lm/appHostLifecycleTools.ts:546

• discover() returns every Aspire candidate, including entries whose status is not buildable; the AppHost view explicitly filters these before exposing lifecycle actions. This loop currently adds those failed candidates to knownAppHosts and allows the tool to pass them to startDebugging, contradicting the PR's buildable-only contract. Filter on candidate.status === 'buildable' before creating a target.

            for (const candidate of candidates) {

extension/src/debugger/AspireDebugConfigurationProvider.ts:156

• Directory scoping is only enabled for the workspace root. A supported launch.json target that names an AppHost subdirectory remains a directory after resolveDebugTarget, but is reserved here as an exact path; that reservation does not overlap the discovered project file, and the parent session also cannot match it until the child session is tracked. During that startup window the agent tool can launch a duplicate AppHost. Resolve the subdirectory to its concrete candidate or reserve any unresolved directory target with directory scope.

                const isDirectoryScope = telemetryTarget === undefined && isWorkspaceFolderLaunch;

extension/src/lm/appHostLifecycleTools.ts:867

• This containment test rejects valid in-workspace names beginning with .., such as ..apps/AppHost.csproj, because it treats every relative.startsWith('..') value as traversal. Such a buildable discovered AppHost is silently omitted from knownAppHosts and can never be started or stopped. Only reject the .. segment itself or a ..${path.sep} prefix.

    if (relative.length === 0 || relative.startsWith('..') || path.isAbsolute(relative)) {

• Files reviewed: 36/36 changed files
• Comments generated: 0 new
• Review effort level: Balanced