[rudycelekli]

Problem

connectStdio and the launcher path decide whether an upstream is a user-supplied docker run with:

(c.config.Command == cmdDocker || strings.HasSuffix(c.config.Command, "/"+cmdDocker)) && len(args) > 0 && args[0] == cmdRun

On Windows the command is often docker.exe or a backslash path such as C:\\Program Files\\Docker\\Docker\\resources\\bin\\docker.exe. Neither matches, so the server goes through the plain shell-wrap branch:

• config.Env isn't injected as -e flags, so the container never sees those variables (API keys etc.). They only reach the docker CLI process.
• No --cidfile is added, and isDockerCommand is false, so the container isn't tracked for cleanup on stop or restart.
• The per-server container lock and ensureNoExistingContainers are skipped.

Fix

Move the check into isDockerRunCommand(command, args). It takes the base name after the last / or \\, compares it case-insensitively, and accepts docker or docker.exe. All four call sites (stdio and launcher, lock and branch) now use it. Behaviour for docker and /path/to/docker is unchanged.

Test

TestIsDockerRunCommand covers bare, POSIX path, docker.exe, upper-case, and both Windows paths, plus negatives (docker ps, no args, docker-compose, dockerize). With the previous predicate the four Windows cases fail; with this change all pass. go test -count=1 ./internal/upstream/core/ passes.

Made with Cursor

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 78.78788% with 7 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/upstream/core/connection_docker.go	75.86%	5 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[Dumbris]

Merged. Thank you, @rudycelekli! A direct docker run server now spawns the docker binary it was configured with instead of whichever one the resolver finds first, so containers start reliably on hosts with more than one docker install. I pushed two small follow-ups to your branch: a configured relative docker path (and a relative working_dir) now resolves the same way, and the test works when the temp dir and checkout sit on different Windows drives.

Contributions like this are what keep MCPProxy moving, and they matter a lot to the project.

One small ask, only if you feel like it: a short public note about your change (a tweet, a LinkedIn post, a line in a community you are part of) helps more people discover MCPProxy. No pressure at all, and I would be glad to repost it.