Question: Handling --exit-code-from premature teardown when dependency services exit

[tejksat]

Context

We are developing an IDE integration where users can run their applications via a specific service defined in compose.yml. To correctly capture and display the exit code of the target application in the IDE terminal, we start the application using the following command:

docker compose up --exit-code-from <app-service> <app-service>

The Problem

The --exit-code-from flag implicitly enables --abort-on-container-exit. This causes unintended behavior when the target <app-service> relies on other utility or one-off containers (e.g., linters, database migrations, log collectors, or user exploration sessions).

When one of these dependency containers exits, the implicit --abort-on-container-exit triggers and shuts down the entire stack—including the still-running primary application. This happens regardless of the dependency's exit status. Whether a migration finishes successfully, a linter fails, or a user runs an incorrect custom command in an exploratory container, the primary app is unexpectedly killed.

Workarounds Considered

We considered bypassing --exit-code-from entirely by splitting the execution into multiple commands:

1. docker compose up -d <app-service>
2. docker compose logs --follow <app-service>
3. docker compose down <app-service> (triggered when stopping the application from the terminal)

While this is technically doable, managing multiple asynchronous calls makes the IDE implementation significantly more convoluted and introduces potential race conditions.

Questions

1. Is this strict abort behavior intended when dependency containers exit, regardless of their exit code or purpose? I would love to understand the design logic behind this.
2. Are there any recommended, cleaner alternatives to capture the target service's exit code without triggering a full stack teardown when side-services exit?

Screen.Recording.2026-05-20.at.19.00.22.mov

Thank you for your time and insights!