Aspire CLI 13.3: SIGABRT on read-only install dir (BundleService cannot write `.aspire-bundle-lock`)

[av-leschinskiy]

Summary

aspire start / aspire run crash with SIGABRT (exit 134) on any deployment where the
directory containing .aspire-wrapped is read-only. The CLI's BundleService attempts
to acquire a lock file .aspire-bundle-lock inside its own installation directory and
extract bundle payload there. On read-only filesystems this fails with EROFS, retries,
then aborts the process.

This breaks:

• NixOS (/nix/store/* is always read-only — fundamental Nix invariant)
• Immutable OSes (Bottlerocket, Flatcar, Talos)
• /opt deployments where install dir is owned by root and CLI runs as non-root user
• Container images that mark install layer read-only

Reproduction

NixOS 26.05, aspire-cli 13.3.0 (also reproducible on any Linux by making install dir read-only):

$ aspire start --isolated --non-interactive --nologo
Starting Aspire AppHost in the background...
❌ AppHost process exited with code 134.
🔍 Check logs for details: /home/user/.aspire/logs/cli_..._detach-child_....log

Diagnosis

strace -f shows hundreds of attempts to create the bundle lock file in the install
directory before SIGABRT:

openat(AT_FDCWD, "/nix/store/.../aspire-cli-13.3.0/.aspire-bundle-lock",
       O_RDWR|O_CREAT|O_CLOEXEC, 0666) = -1 EROFS (Read-only file system)
[repeated ~80 times across threads]
+++ killed by SIGABRT (core dumped) +++

Parent CLI log (cli_*.log) confirms — repeated entries from BundleService:

[DBUG] [BundleService] Ensuring bundle is extracted to /nix/store/.../aspire-cli-13.3.0.
[DBUG] [BundleService] Acquiring bundle extraction lock at
                       /nix/store/.../aspire-cli-13.3.0/.aspire-bundle-lock...

Coredump backtrace confirms abort during managed startup (CoreCLR abort() from native frame).

Also ruled out: DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true does not help — same SIGABRT, ICU
is not loaded but BundleService still fails first.

What works / what doesn't

Command	Works on read-only install dir?
aspire --version, aspire --help, aspire doctor, aspire ps, aspire certs trust	✅
aspire start, aspire run	❌ SIGABRT

The crash correlates exactly with commands that need BundleService extraction.

Workaround

Bypass CLI entirely — run AppHost directly via dotnet:

DcpPublisher__RandomizePorts=true \
  dotnet run --project path/to/AppHost.csproj --launch-profile https

dotnet run does not touch BundleService.

Suggested fix

BundleService should extract bundle to a writable user-scoped location instead of the
CLI install directory. Options:

1. $XDG_CACHE_HOME/aspire/bundle/<binary-hash> (or $HOME/.cache/aspire/... fallback)
2. Add an env var override for the bundle cache path
3. Detect read-only install dir (writable check on init), fall back to user cache
   automatically, log a [WARN]

Additionally, the current failure mode (abort() without error message) is unhelpful.
The CLI should catch EROFS from the lock file openat, log a clear error, and exit
with a non-zero code — not abort.

Environment

• NixOS: BUILD_ID=26.05.20260515.d233902 (kernel 6.18.28, glibc 2.42)
• aspire-cli: 13.3.0+4517e4a1ffb7f00a4c0e66882c2db952d637c0cc
• .NET SDK: 10.0.100 (works correctly — only AOT CLI binary is affected)
• Mode: bundled AOT (.aspire-wrapped, 136 MB single-file publish)

Full coredump, strace logs, and CLI logs available on request.

[joperezr]

🤖 Aspire triage pass — 2026-05-19 10:20 UTC

Area: area-cli, area-acquisition
Kind: bug
Repro: yes-minimal — strace + CLI log excerpts in body, command line + environment fully specified
Affected version(s): 13.3.0 (latest servicing line: 13.3.x)
Severity: S2 — aspire start / aspire run (core CLI scenarios) crash with SIGABRT on read-only install dirs (NixOS, immutable OSes, /opt-style deployments, read-only container layers). Workaround exists (dotnet run against AppHost).

Urgency: 🟡 vNext — recommend milestone 13.4
Reason: S2 with documented workaround; affects a class of platforms (read-only install dirs) rather than the default install path. Regression baseline vs. 13.2 unclear — the AOT bundled CLI / BundleService extraction model appears to be a 13.3-era change, so this is not obviously a regression in shipping bits. Suggested fix (relocate bundle extraction to $XDG_CACHE_HOME / user cache) is a non-trivial behavior change better suited to a minor than a patch.

Suggested owner(s): @JamesNK (primary), backup @mitchdenny
Evidence:

• @JamesNK authored the vast majority of recently merged area-cli PRs in the last 90d (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, Echo selection prompt result after interactive selection #16996, Add --search option to aspire logs and aspire otel commands #16939, Trim whitespace in markdown link text and extract MarkdownLinkConverter #16926, Add --yes validation to UpdateCommand and share validation logic #16829, Fix aspire run failing when DisableDashboard is true #16773, Improve CLI init output spacing #16718, [release/13.3] Normalize *.localhost dashboard URLs to localhost for CLI HTTP requests #16708, [release/13.3] Rename pipeline --log-level to --pipeline-log-level to avoid CLI log overlap #16596, Improve confirm prompt UX in ConsoleInteractionService #16553, Mark DashboardCommand and DashboardRunCommand as preview commands #16548, Update Aspire skill monitoring output guidance #16524, Refactor CLI telemetry JSON output to match MCP tool format #16523, Improve CLI docs markdown rendering and simplify DocsGetCommand #16428, Use CheckMarkButton emoji instead of CheckMark for consistent green rendering #16373, Update Spectre.Console to 0.55.2 and simplify EmojiWidth #16349, Add telemetry activity for running app host in CLI #16346, Make trace ID a clickable link in trace detail view #16345, … — dominant author by count and recency).
• @JamesNK closed multiple area-cli issues as completed in the last 180d (Use quotes when referencing a full file path #16788, [13.3] aspire run on an already running app host doesn't stop existing cli session gracefully #16732, [13.3] Clarify what version numbers are what in CLI log file #16728, [13.3] aspire start --isolated kills any other instances running #16727, Can't get apphost logs if you miss the startup logs link #16721, [13.3] aspire config set still writes booleans as JSON strings (write-path fix from PR #15638 didn't ship) #16692, [13.3] aspire new --non-interactive silently overwrites inferred output directory #16646, [13.3] aspire run and aspire start behave differently if DisableDashboard = true #16619, aspire otel standalone dashboard UX is confusing around --dashboard-url and --enable-api #16236, When started under isolated mode, no Traces and metrics are displayed in the Aspire dashboard #16037).
• CODEOWNERS for /src/Aspire.Cli: @mitchdenny @JamesNK @davidfowl. BundleService lives under src/Aspire.Cli/Bundles (verified path: src/Aspire.Cli/Bundles exists in the repo).
• @mitchdenny is a CODEOWNER and has closed/assigned several recent area-cli issues ([13.3] aspire run ignores *.dev.localhost url in aspire.config.json #16725, aspire init fails on repos with a .sln when CLI is a non-stable build (staging/daily/PR) — InitCommand bypasses channel feed wiring #16654, aspire update --channel staging can select daily package versions from a daily CLI #16652, Aspire CLI update ignores configured channel and silently falls back to implicit NuGet.config channel #16650, aspire 13.3 - aspire --apphost directory doesn't work due to added aspire-managed suffix #16513) — strong backup.

Confidence: medium
Needs human?: no — but flagging that the fix shape (relocate bundle extraction to a user-writable cache, plus better error handling on EROFS) is a design decision that should be confirmed by the owner before implementation.

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

[radical]

cc @joperezr @DamianEdwards