Repository navigation
Compose provider extensions/plugins can only execute ".exe" on windows #14157
Description
Activity
- changed the title
[-]Compose provider extensions/pplugins can only execute ".exe" on windows[/-][+]Compose provider extensions/plugins can only execute ".exe" on windows[/+]on Sep 1, 2026 You're right — thanks for the report. The hardcoded
.exein the PATH fallback was actually redundant even for compiled binaries:exec.LookPathalready implements Windows executable resolution and tries each PATHEXT extension (.com/.exe/.bat/.cmdby default), so appending the suffix only narrowed the lookup. Fix: #14159 drops it and looks up the bare provider name.Two caveats worth stating:
- This only affects the PATH fallback of provider discovery. The docker CLI plugin channel (
docker-<name>incli-plugins) keeps requiring.exeon Windows — that convention belongs to docker/cli. .py(or anything relying on a file association) still won't work even when listed in PATHEXT: providers are spawned viaCreateProcess, which does not honor associations. In practice this enables what Windows can execute directly —.exe,.com, and batch files. For batch files, the Go runtime mitigates the cmd.exe argument-injection class (BatBadBut) by refusing arguments it cannot safely escape. A script-based provider is best shipped as a.cmdshim or a compiled launcher.
- This only affects the PATH fallback of provider discovery. The docker CLI plugin channel (
- added a commit that references this issue
on Sep 1, 2026 @ndeloof wouldn't it be possible to support file associations on Windows e.g. instead of CreateProcess to use ShellExecute? Of course a shim works, but it imposes some additional frictions you need to go through for support both platforms. So if you use ShellExecute and have a more faithful adaption, wouldn't that be overall better?
Metadata
Metadata
Assignees
Labels
No labels
The Windows plugin discovery currently appears to restrict plugins to .exe files. I'm not sure this is desirable behavior.
compose/pkg/compose/plugins_windows.go
Line 22 in b328491
On Windows, executable command resolution normally respects PATHEXT, which allows extensions such as .CMD, .BAT, and potentially .PY (depending on the environment) to be invoked without explicitly specifying the extension.
Restricting Compose plugins to .exe therefore prevents lightweight script-based plugins. For example, a plugin could be implemented as a Python, batch, or other script rather than requiring a compiled executable.
I think plugin discovery should probably respect PATHEXT (or otherwise use the same executable-resolution semantics as Windows), rather than hard-coding .exe.
This would also make Compose plugin behavior more consistent with how commands are normally resolved on Windows.