Stdio Docker MCP containers remain running after closing a session
Personne n'a encore pris cette issue.
- Langage dominant
- Shell
- Étoiles
- 11.2k
- Forks
- 1.9k
- Merge moyen
- 14 h 16 min
- PR mergées (30 j)
- 6
Description
Describe the bug
When multiple Copilot CLI sessions use local stdio MCP servers running in Docker, closing one session does not terminate the Docker containers started for that session.
The behavior occurs with both:
- A direct Docker MCP.
- A Node wrapper that starts.
Because both MCP implementations reproduce the problem, this appears to be a Copilot CLI stdio MCP lifecycle issue rather than a problem in either Docker image.
After using multiple sessions, docker ps showed three active instances of each image:
matheusrhgestor/html2pdf-mcp
matheusrhgestor/html2pdf-mcp
matheusrhgestor/html2pdf-mcp
matheusrhgestor/kendo-ui-doc
matheusrhgestor/kendo-ui-doc
matheusrhgestor/kendo-ui-doc
In one reproduction:
- A session was resumed around 11:45 local time.
- Its session shutdown was recorded around 11:54 local time.
- The
kendo-ui-docandhtml2pdf-mcpcontainers created around 11:44 remained inUpstate afterward. - A new active session started another pair around 11:55.
Representative container output:
052529bdf996|matheusrhgestor/html2pdf-mcp|Up 7 minutes
1793cf8f1aad|matheusrhgestor/kendo-ui-doc|Up 7 minutes
9870e1fd5c7f|matheusrhgestor/html2pdf-mcp|Up 18 minutes
d1bc7dd02cd6|matheusrhgestor/kendo-ui-doc|Up 18 minutes
e161b8af2fb7|matheusrhgestor/html2pdf-mcp|Up 39 minutes
fc11f628ff81|matheusrhgestor/kendo-ui-doc|Up 39 minutes
Affected version
1.0.79
Steps to reproduce the behavior
-
Configure the
kendo-ui-docMCP as a local stdio server using Docker:{ "type": "local", "command": "docker", "args": [ "run", "--rm", "-i", "matheusrhgestor/kendo-ui-doc" ] } -
Configure the
html2pdfMCP as a local stdio server using a Node wrapper that starts:docker run --rm -i --mount ... matheusrhgestor/html2pdf-mcp -
Start Copilot CLI session A and verify that one container per MCP is running.
-
Start Copilot CLI session B and verify that a second pair of containers is running.
-
Close session A using the normal session exit action, such as
/exitorCtrl+D. -
Run:
docker ps --all --format "{{.ID}}|{{.Image}}|{{.Status}}|{{.Names}}|{{.CreatedAt}}" -
Observe that the containers created for session A are still running.
Expected behavior
Closing a session should disconnect its stdio MCP processes and stop/remove only the containers created by that session.
The --rm option should remove each container after the corresponding docker run process is terminated.
Containers belonging to other active Copilot CLI sessions should remain running.
Additional context
- Operating system: Windows 11 Pro
- Architecture: x64
- Shell: command prompt
- MCP transport: local stdio
- Docker images:
matheusrhgestor/kendo-ui-docmatheusrhgestor/html2pdf-mcp
The direct kendo-ui-doc configuration uses docker run --rm -i.
The html2pdf wrapper uses Node child_process.spawn with stdio: "inherit" and also starts Docker with --rm -i. Therefore, --rm cannot clean up the container while the Docker process is still alive.
The issue is reproducible across more than one session and more than one MCP implementation. The likely failure is that closing a Copilot CLI session does not propagate termination to the local stdio MCP process and its Docker child process.
This appears related to:
https://github.com/github/copilot-cli/issues/4049
https://github.com/github/copilot-cli/issues/3440
This report concerns concurrent sessions and closing one session, rather than only /new or /resume.
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par reproduire le problème avec deux sessions Copilot CLI utilisant des commandes MCP stdio locales lancées via Docker, puis suivez le chemin d’arrêt de la session pour ces processus enfants. Le travail est considéré comme terminé lorsque la fermeture d’une session arrête et supprime uniquement ses conteneurs Docker, tandis que les conteneurs de l’autre session active continuent de s’exécuter.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- docker, node.js
- Domaine
- cli, devops
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 52/100