Extend AppHost debug startup timeout from VS Code

[adamint]

Description

Sets a long default ASPIRE_CLI_START_TIMEOUT for VS Code extension-managed AppHost debug sessions so pausing on a breakpoint before builder.Build() does not let the parent Aspire CLI hit its normal startup timeout and terminate the debug session.

The default only applies to extension-managed debug launches. Extension-managed run sessions keep the normal CLI timeout, and an explicitly configured ASPIRE_CLI_START_TIMEOUT still wins, including case-insensitive Windows env overrides.

This also aligns the parent CLI's AppHost backchannel wait with a larger configured AppHost startup timeout. That keeps the extension-launched AppHost path from timing out the backchannel before the configured startup timeout expires.

Follow-up review fixes:

• Redact hidden CLI spawn diagnostics after the -- delimiter so resource command argument values, including secret prompt values, are not persisted in extension logs.
• Merge caller-provided spawn environment variables case-insensitively on Windows, and report the effective startup timeout in diagnostics with the same lookup.

Fixes #18021

Validation:

• ./restore.sh
• dotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj --no-launch-profile -- --filter-class "*.DotNetCliRunnerTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true" (63 passed)
• cd extension && ./build.sh
• cd extension && corepack yarn run compile-tests
• cd extension && corepack yarn run compile && corepack yarn run lint
• cd extension && ./node_modules/.bin/vscode-test --config .vscode-test-short.mjs --grep "spawnCliProcess tests" with short --user-data-dir (5 passed; temporary config removed)
• cd extension && ./node_modules/.bin/vscode-test --config .vscode-test-short.mjs with short --user-data-dir (full VS Code unit suite exited 0; temporary config removed)
• Focused local debugStartupTimeout E2E was attempted, but local fixture restore was blocked before the scenario by NU1507 package-source mapping warning-as-error from the local NuGet source configuration.
• Current CI head a783cccaa36d44965115821828818ebd66569cc2: VS Code extension E2E debug-startup-timeout Linux and Windows shards passed. Linux diagnostics include an mp4 recording; both shards show ASPIRE_CLI_START_TIMEOUT=86400 and a ~65s pre-builder.Build() delay completing without timeout. The first full CI attempt hit a DoctorCommand_TypeScriptAppHostReportsMissingConfiguredToolchain(toolchain: "yarn") timeout in Cli.EndToEnd-DoctorCommandTests; rerunning failed jobs passed and the full CI run is now green.

Review panel:

• Architecture/simplicity: Opus high (reviewing-aspire-architecture), no blocking findings
• Edge cases/regressions: GPT-5.5 high, no blocking findings
• Domain review: Opus high using Aspire code-review guidance, no blocking findings after fixes
• PR tester proof: GPT-5.4 high, current-head Linux/Windows E2E artifacts verified real Extension Host proof; failed CI rerun passed

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

[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 -- 18353

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

This PR fixes issue #18021, where a VS Code extension debug session was killed after ~2 minutes when the developer paused on a breakpoint before builder.Build(). The parent Aspire CLI's default AppHost startup timeout (ASPIRE_CLI_START_TIMEOUT, ~120s) would elapse while the AppHost was paused, terminating the session. The fix has the extension inject a very long default startup timeout (86400 = 24h) only for extension-managed debug launches, while leaving run sessions and explicitly configured timeouts untouched.

Changes:

• Add ASPIRE_CLI_START_TIMEOUT to the extension's EnvironmentVariables enum.
• In AspireTerminalProvider.createEnvironment, set ASPIRE_CLI_START_TIMEOUT='86400' for debug sessions (noDebug === false) unless the value is already present in the environment.
• Add unit tests covering debug (sets timeout), run (no timeout), and explicit-override (preserved) cases, with proper env-var save/restore in setup/teardown.

Show a summary per file

File	Description
extension/src/utils/environment.ts	Adds the ASPIRE_CLI_START_TIMEOUT enum member so the timeout key is referenced consistently.
extension/src/utils/AspireTerminalProvider.ts	Sets the long default startup timeout for extension-managed debug sessions, respecting any explicit value.
extension/src/test/aspireTerminalProvider.test.ts	Adds tests for the new behavior with env-var isolation in setup/teardown.

Notes:

• The precedence logic is correct: env is seeded from process.env, so an explicitly configured ASPIRE_CLI_START_TIMEOUT is preserved (verified by the test at lines 586–598).
• The noDebug === false check matches the existing convention in this method (lines 282–283) for distinguishing Debug vs NoDebug sessions, and the value is consumed by the CLI's CliConfigNames.AppHostStartupTimeout as integer seconds.
• One optional nit was raised about documenting the '86400' magic number, consistent with the surrounding WHY-commented code.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 1

[Copilot]

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0 new

[Copilot]

Copilot's findings

• Files reviewed: 5/5 changed files
• Comments generated: 0 new

[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]

Copilot's findings

• Files reviewed: 10/10 changed files
• Comments generated: 0 new

[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]

Copilot's findings

• Files reviewed: 10/10 changed files
• Comments generated: 1

[adamint]

(automated comment) Validation/evidence update for current head a783cccaa36d44965115821828818ebd66569cc2:

• Local: ./restore.sh passed.
• Local: dotnet test --project tests/Aspire.Cli.Tests/Aspire.Cli.Tests.csproj --no-launch-profile -- --filter-class "*.DotNetCliRunnerTests" --filter-not-trait "quarantined=true" --filter-not-trait "outerloop=true" passed (63/63).
• Local: cd extension && ./build.sh, corepack yarn run compile-tests, corepack yarn run compile && corepack yarn run lint passed.
• Local: VS Code unit tests required a short --user-data-dir because the DevDrive worktree path hits the VS Code IPC socket limit; targeted spawnCliProcess tests passed (5/5), and the full VS Code unit suite exited 0 with the short config.
• Real-path proof: current CI debug-startup-timeout E2E passed on Linux and Windows:
  • Linux job: https://github.com/microsoft/aspire/actions/runs/27881145066/job/82509917744 (diagnostics artifact includes mp4 recording)
  • Windows job: https://github.com/microsoft/aspire/actions/runs/27881145066/job/82509917722
  • Both logs show ASPIRE_CLI_START_TIMEOUT=86400, a ~65s pre-builder.Build() delay, and no timeout.

Focused local E2E was attempted, but local fixture restore failed before the scenario with NU1507 package-source mapping warning-as-error from the local NuGet source configuration. CI has the strongest real Extension Host proof for this path.