mxcli test --local downloads Linux mxbuild into Windows $USERPROFILE/.mxcli/mxbuild with no override to redirect to Windows binary

[cheealtair]

Body

Environment

• OS: Windows 11 Enterprise (22631)
• mxcli version: v0.21.0 (2026-09-06)
• Mendix Studio Pro: 11.11.0 installed at C:\Program Files\Mendix\11.11.0\
• Shell: Git Bash (MSYS2 on Windows)
• Author: Clinton Chee DI SW GS&CS MXRM APAC PRS T2

Summary

mxcli test --local on Windows downloads a Linux ELF mxbuild binary into
%USERPROFILE%\.mxcli\mxbuild\{version}\modeler\mxbuild. This binary cannot
execute on Windows. There is no --mxbuild-path flag, no MXCLI_MXBUILD_PATH
environment variable, and no other mechanism to redirect mxcli to the Windows
mxbuild.exe already present in the Studio Pro installation. The result is that
mxcli test --local is entirely non-functional on Windows.

Steps to reproduce

1. Windows machine with Studio Pro 11.x installed (mxbuild.exe at
   C:\Program Files\Mendix\{version}\modeler\mxbuild.exe)
2. Run mxcli test tests/ -p MyApp.mpr --local
3. mxcli downloads a Linux ELF binary to
   %USERPROFILE%\.mxcli\mxbuild\{version}\modeler\mxbuild
4. mxcli attempts to execute it; the process fails to start

Observed error:

Error: local runtime: starting mxbuild serve: mxbuild --serve did not become ready: mxbuild --serve exited during startup
--- mxbuild output ---
(empty -- Linux ELF cannot execute on Windows)

What was attempted (and why it made things worse)

This issue was encountered by Claude Code (AI coding assistant,
claude-sonnet-4-6) working autonomously on behalf of a developer. In
attempting to unblock mxcli test --local, Claude Code made the following
modifications to %USERPROFILE%\.mxcli\mxbuild\11.11.0\modeler\:

Action	File
Renamed (backup)	mxbuild -> mxbuild.linux
Added	mxbuild -- copy of Studio Pro mxbuild.exe (Windows PE32+, 174 KB)
Added	mxbuild.exe -- same copy
Replaced	mxbuild.runtimeconfig.json -- changed from includedFrameworks (self-contained/Linux) to framework (framework-dependent, targets installed .NET 10)
Added	e_sqlite3.dll -- native SQLite DLL from Studio Pro runtimes\win-x64\native\
Added	runtimes\win-x64\native\e_sqlite3.dll -- same DLL
Added	tools\deno\win-x64\deno.exe -- copied from Studio Pro (121 MB)

This produced a mixed Linux/Windows cache that is fragile, unsupported, and will
be silently destroyed the next time mxcli re-downloads mxbuild for this version.
The developer's environment has been left in a degraded state. This entire chain
of manual surgery would have been avoided by a single --mxbuild-path flag or
env var.

Root cause

mxcli test --local discovers mxbuild exclusively from its own internal cache
(%USERPROFILE%\.mxcli\mxbuild\) with no override mechanism. On Windows, it
downloads a Linux-targeted binary rather than the Windows binary. The Windows
mxbuild.exe is already present in the Studio Pro installation but is
unreachable by mxcli.

Note: the mxcli project toolkit (_common.sh) already implements a correct
resolution order -- $MXBUILD_PATH -> Studio Pro install -> cache -- for its
own gate scripts. The same logic does not exist inside the mxcli binary itself.

Suggested fixes (in order of preference)

1. --mxbuild-path flag / MXCLI_MXBUILD_PATH env var on
   mxcli test --local (and mxcli run --local) -- lets the caller point
   directly at Studio Pro's mxbuild.exe. Mirrors what the toolkit's
   _common.sh already does with $MXBUILD_PATH.

2. Platform-correct download on Windows -- when mxcli detects it is running
   on Windows, download the Windows mxbuild package rather than the Linux one.

3. Auto-discover Studio Pro on Windows before downloading -- mirror
   find_mxbuild() from _common.sh: check
   C:\Program Files\Mendix\{version}\modeler\mxbuild.exe before falling back
   to a download.

Additional suggestion: DevContainer / Windows cache isolation

If the Linux mxbuild cache at ~/.mxcli/mxbuild/ is intended for use inside a
DevContainer (where a Linux runtime is available), and the DevContainer mounts
or symlinks ~/.mxcli/mxbuild from the Windows host's
%USERPROFILE%\.mxcli\mxbuild, that mount causes the Linux stack to appear at
the Windows path -- which is exactly what triggered this issue.

Proposed alternative: keep the Linux mxbuild cache inside the
DevContainer's own filesystem rather than mounting it from the Windows host. The
Linux binaries are only useful inside the container; exposing them on the Windows
host profile creates the confusion described above. If the DevContainer must
share state with the host, a separate mount point (e.g.
~/.mxcli/mxbuild-linux/) would avoid polluting the Windows-side path that
mxcli also reads.

Expected behaviour

mxcli test --local on Windows should either:

• (a) auto-discover and use the Studio Pro mxbuild.exe, or
• (b) accept a --mxbuild-path flag / MXCLI_MXBUILD_PATH env var, or
• (c) print a clear, actionable error explaining that the cached binary is not
  executable on this platform and describing how to supply a Windows binary --

rather than silently downloading a non-runnable Linux binary and failing with an
opaque startup error.