Feedback source
External user feedback (travel multi-agent workshop team using shell for data seeding in azd post-provision scripts).
Problem
The Azure Cosmos DB Shell is packaged as a self-contained .NET application. The platform-specific NuGet packages are roughly 50-60 MB compressed and expand to about 200 MB installed because they include the .NET runtime and dependencies.
For CI/CD scenarios with ephemeral (or un-cached self-hosted) runners, this is a friction point because users must reacquire the full package on every invocation.
Root cause
The same executable bundles:
- Interactive shell features
- Cosmos data access
- ARM management
- Azure authentication
- MCP/ASP.NET hosting
- LSP support
- OpenTelemetry
Most of that is unnecessary for typical CI/CD use cases (seeding test data, CRUD, queries, validating integration tests).
Suggested approaches
- .NET trimming or Native AOT to reduce size
- Feature-split distributions (see related issue for lightweight CI distribution)
- Investigate alternative runtimes (Go/Rust) for the CI-only variant
Impact
Blocks frictionless adoption in GitHub Actions and other ephemeral CI environments where cache misses are common.
Feedback source
External user feedback (travel multi-agent workshop team using shell for data seeding in azd post-provision scripts).
Problem
The Azure Cosmos DB Shell is packaged as a self-contained .NET application. The platform-specific NuGet packages are roughly 50-60 MB compressed and expand to about 200 MB installed because they include the .NET runtime and dependencies.
For CI/CD scenarios with ephemeral (or un-cached self-hosted) runners, this is a friction point because users must reacquire the full package on every invocation.
Root cause
The same executable bundles:
Most of that is unnecessary for typical CI/CD use cases (seeding test data, CRUD, queries, validating integration tests).
Suggested approaches
Impact
Blocks frictionless adoption in GitHub Actions and other ephemeral CI environments where cache misses are common.