Dev containers still not stopped on exit — Cursor 3.12.17 (macOS), "shutdownAction": "stopContainer" has no effect

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Containers started by a Docker Compose–based dev container keep running after Cursor is fully quit. The same happens when switching between dev containers. A manual docker compose down is required every time.

This has been reported twice before and is still open:

Filing fresh rather than reviving those because it still reproduces on 3.12.17 — the behaviour has now survived two major versions and shows up on a third OS.

A staff reply on the November thread asked that reporter three questions. Answering all three up front:

  1. Config type: Docker Compose based.
  2. "shutdownAction": "stopContainer" in devcontainer.json: no effect — containers are still running after quitting. Same result the earlier reporter got.
  3. Anysphere Remote Containers extension version: [FILL IN — Extensions panel, search “Remote - Containers”]

Steps to Reproduce

  1. Open a project with a Docker Compose–based .devcontainer configuration.
  2. Run “Dev Containers: Reopen in Container” and let it build and attach.
  3. Quit Cursor entirely — Cmd+Q on macOS, not just closing the window.
  4. Run docker ps. The container(s) from step 2 are still running.
  5. Add "shutdownAction": "stopContainer" to devcontainer.json, rebuild, and repeat steps 2–4. The containers are still running — the setting makes no difference.

Switching directly from one dev container to another (without quitting) leaves the first one running too.

Expected Behavior

Quitting Cursor should stop the containers it started for the dev container, and switching to a different dev container should stop the one being left. Setting "shutdownAction": "stopContainer" should at minimum force that behaviour.

Operating System

MacOS

Version Information

Version: 3.12.17
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.6.0

Additional Information

Reproduces on two separate machines — macOS (arm64) and Linux — so this does not look OS-specific. Combined with the earlier Linux and Windows/WSL2 reports, the behaviour now has reports on all three platforms.

Container runtime on macOS: Colima

Impact: not blocking. Cursor is fully usable, but across a day of switching between projects it leaves orphaned containers holding memory, and each one has to be cleaned up by hand.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report, and extra thanks for answering all three questions from the November thread up front. That really speeds up the investigation.

Confirmed: we can reproduce this with Docker Compose dev containers, and shutdownAction really doesn’t affect the outcome in this case. It shouldn’t work like this, and it’s not something in your setup. I’ve passed this to the team along with the earlier threads you shared (Linux and Windows/WSL2). The symptom is the same.

A few practical notes while this is being worked on:

  • You don’t need to share the Anysphere Remote Containers version. The issue reproduces regardless of it.
  • Like you’re doing, the most reliable workaround for compose configs is to run docker compose down (or stop) manually after you exit.
  • Side note: for compose configs, the correct shutdownAction value in the spec is stopCompose, not stopContainer. It doesn’t change the current behavior (containers don’t stop either way), but keep it in mind for the future.

I can’t share a timeline yet, but I’ll reply in this thread when there’s an update.