Summary
On macOS, mxcli run --local (and test --local) picks up the cached Linux CDN mxbuild and fails with a raw exec format error. setup mxbuild and docker build do not do this — both correctly resolve Studio Pro's macOS mxbuild instead. The resolution logic is inconsistent between the local-runtime path and the other two, and the failure message does not say what is wrong.
Environment
|
|
| mxcli |
v0.18.0 (2026-08-14T20:29:13Z), official darwin-arm64 release binary |
| Mendix |
11.12.0 |
| OS |
macOS 15 (Darwin 25.6.0), arm64 |
Precondition: ~/.mxcli/mxbuild/11.12.0/ contains a CDN-downloaded mxbuild, i.e. a Linux binary. On this machine it arrived from an earlier version or a --force.
$ file ~/.mxcli/mxbuild/11.12.0/modeler/mxbuild
ELF 64-bit LSB pie executable, ARM aarch64, ... for GNU/Linux 3.7.0
Reproduction
mxcli run --local -p app.mpr --test-endpoint --app-port 8085 --admin-port 8095 --serve-port 6547
Ensuring MxBuild and runtime are available...
MxBuild 11.12.0 already cached at /Users/<me>/.mxcli/mxbuild/11.12.0/modeler/mxbuild
Starting mxbuild --serve...
Error: starting mxbuild serve: starting mxbuild --serve: fork/exec
/Users/<me>/.mxcli/mxbuild/11.12.0/modeler/mxbuild: exec format error
mxcli test <file> -p app.mpr --local fails identically.
The inconsistency
The other two commands get this right on the same machine, with the same cache present:
mxcli setup mxbuild -p app.mpr
Using Studio Pro mxbuild for 11.12.0: /Applications/Mendix Studio Pro 11.12.0 Beta.app/Contents/modeler/mxbuild
(No download needed. Re-run with --force to download the Linux CDN binary instead.)
mxcli docker build -p app.mpr
Resolving MxBuild...
MxBuild: /Applications/Mendix Studio Pro 11.12.0 Beta.app/Contents/modeler/mxbuild
So mxcli already knows both that the CDN binary is Linux-only and how to find a macOS mxbuild. run --local just does not use that knowledge.
Expected
Any of these would resolve it:
run --local / test --local use the same resolver as setup and docker build — prefer Studio Pro's mxbuild on macOS.- Reject a cached binary whose platform does not match the host, with a message naming the cause and the fix, rather than surfacing
exec format error.
- If the local runtime genuinely cannot work on macOS, say so up front instead of failing at mxbuild launch.
Option 2 is the minimum: exec format error gives a user no path forward.
Impact
Both of mxcli's Docker-free runtime paths are unusable on a macOS machine in this state, with no message indicating why. The workaround (delete the cache so the Studio Pro binary is found) is not discoverable from the error.
Summary
On macOS,
mxcli run --local(andtest --local) picks up the cached Linux CDN mxbuild and fails with a rawexec format error.setup mxbuildanddocker builddo not do this — both correctly resolve Studio Pro's macOS mxbuild instead. The resolution logic is inconsistent between the local-runtime path and the other two, and the failure message does not say what is wrong.Environment
Precondition:
~/.mxcli/mxbuild/11.12.0/contains a CDN-downloaded mxbuild, i.e. a Linux binary. On this machine it arrived from an earlier version or a--force.Reproduction
mxcli run --local -p app.mpr --test-endpoint --app-port 8085 --admin-port 8095 --serve-port 6547mxcli test <file> -p app.mpr --localfails identically.The inconsistency
The other two commands get this right on the same machine, with the same cache present:
mxcli setup mxbuild -p app.mprmxcli docker build -p app.mprSo mxcli already knows both that the CDN binary is Linux-only and how to find a macOS mxbuild.
run --localjust does not use that knowledge.Expected
Any of these would resolve it:
run --local/test --localuse the same resolver assetupanddocker build— prefer Studio Pro's mxbuild on macOS.exec format error.Option 2 is the minimum:
exec format errorgives a user no path forward.Impact
Both of mxcli's Docker-free runtime paths are unusable on a macOS machine in this state, with no message indicating why. The workaround (delete the cache so the Studio Pro binary is found) is not discoverable from the error.