Summary

A single Docker Compose project using a different set of overlay yml files for services is split into multiple separate sidebar stacks (groups).

The groups carry the identical project name and re-sort unpredictably on every expand/collapse (they jump around), and Stop/Delete on one group stops the entire stack.

Appears to be a regression in recent 2.2.x.

Environment

• OrbStack: 2.2.1 (20628)
• macOS 14.x (Apple Silicon)

Why one project legitimately has multiple config_files sets

Normal, supported Compose usage. Within one project, different services are (re)started with different -f overlay combinations e.g. some services are restarted in dev mode with an overlay:

NAME              com.docker.compose.project   config_files
myproj_litellm    myproj                       compose.yml
myproj_chatapp    myproj                       compose.yml,compose.dev.yml

Each docker compose up <svc> -f ... stamps the containers it touches with that invocation's config_files. Docker treats them as one project (keyed on project name); only the OrbStack UI sub-divides them.

Current behavior

• Orbstack Containers shows two stacks groups, both labeled myproj, visually indistinguishable when collapsed
• Sort order is unstable, the groups reorder on every expand/collapse - very annoying.
• Stop / Delete on any group applies to the entire stack - counter-intuitive for the UI/UX.

Expected behavior

Option 1: revert a recent change. Group stacks by project name as Docker does. Matches docker compose's own model and earlier OrbStack behavior.

Option 2: If sub-grouping by config_files is intentional,

• Visually disambiguate each group by showing its config_files (e.g. + compose.dev.yml) as a subtitle/badge.
• Make the sort order stable by a deterministic key (project name, then config_files) so groups don't jump around
• Scope Stop/Delete only to the services under the (group) which user has operated on