mxcli docker run fails on Apple Silicon: Studio Pro 11.10.0 Beta launches x86_64 Deno, panics under Rosetta

[dimenus]

Field	Status	Value
mxcli version	✅	v0.10.0-dirty (2026-05-13T20:04:50Z)
Mendix version	✅	11.10.0 (Studio Pro 11.10.0 Beta)
Host	✅	macOS 24.6.0 (Sequoia), Apple Silicon (arm64)
Scenario	✅	mxcli docker run -p Foresight.mpr
Expected	✅	MxBuild completes, runtime starts in Docker
Experienced	✅	MxBuild aborts when the web-extensions runner crashes the bundled Deno

Summary

On Apple Silicon Macs, mxcli docker run (and any other path that
invokes Studio Pro 11.10.0 Beta's bundled mxbuild) fails because
MxBuild's web-extensions runner launches the x86_64 Deno binary
under Rosetta 2 instead of the native arm64 Deno that ships in the
same Studio Pro bundle. Deno 2.7.5 then panics with
Check failed: 12 == (*__error()) (errno 12 = ENOMEM, a known
Rosetta-2 / V8 init issue), MxBuild times out waiting for the
component host, and the build never produces a PAD package.

The bug is in Studio Pro, not mxcli — mxcli is doing the right
thing by delegating to Studio Pro's bundled MxBuild. We're filing this
here for visibility because every mxcli user on an Apple Silicon Mac
with Studio Pro 11.10.0 Beta installed will hit it, and mxcli is
positioned to detect / warn / auto-patch.

Output

Using Studio Pro installation: /Applications/Mendix Studio Pro 11.10.0 Beta.app/Contents
…
Checking project for errors...
  Project check passed.       ← project itself is fine (0 errors)
Running MxBuild (target=portable-app-package)...
…
Preparing the web extensibility environment...
[WebExtensionsRunner] > Deno has panicked. This is a bug in Deno.
[WebExtensionsRunner] > Platform: macos x86_64
[WebExtensionsRunner] > Version: 2.7.5
[WebExtensionsRunner] > Args: [".../modeler/tools/deno/osx-x64/deno", "run", …]
[WebExtensionsRunner] > thread 'main' (8496192) panicked at cli/lib.rs:565:5:
[WebExtensionsRunner] > Fatal error in :0: Check failed: 12 == (*__error()).
ERROR: System.Exception: Component Host failed to start within the expected time.
Error: docker build: mxbuild failed: exit status 1

Studio Pro bundle layout

$ file "/Applications/Mendix Studio Pro 11.10.0 Beta.app/Contents/MacOS/studiopro"
… Mach-O 64-bit executable x86_64
$ file ".../modeler/mxbuild"
… Mach-O 64-bit executable x86_64

$ ls   ".../modeler/tools/deno/"
osx-arm64
osx-x64

$ file ".../modeler/tools/deno/osx-arm64/deno"
… Mach-O 64-bit executable arm64        ← native, unused
$ file ".../modeler/tools/deno/osx-x64/deno"
… Mach-O 64-bit executable x86_64       ← gets selected, panics under Rosetta

The native arm64 Deno is right there. The web-extensions runner just
picks the x86_64 path based on the calling process's architecture
(which is x86_64 under Rosetta) instead of the hardware architecture
(arm64).

Confirmed root cause via workaround

Pointing mxcli docker run at a patched copy of MxBuild — same
binary, except the arm64 Deno is copied over the x86_64 path —
succeeds:

DEST="$HOME/.mxbuild-patched-11.10.0"
cp -R "/Applications/Mendix Studio Pro 11.10.0 Beta.app/Contents/modeler/" "$DEST/"
cp -a "$DEST/tools/deno/osx-arm64/deno" "$DEST/tools/deno/osx-x64/deno"

mxcli docker run --mxbuild-path "$DEST/mxbuild" -p Foresight.mpr

After the swap, MxBuild completes and the Docker stack comes up
cleanly. So the panic is not a real Deno bug, not a project bug, not
an mxcli bug — it's Studio Pro pointing at the wrong Deno on ARM.

Modifying the Studio Pro bundle in-place fails on Sequoia 15+ even
under sudo because of macOS App Management protection — the
out-of-tree mxbuild copy + --mxbuild-path was the only viable fix.

Filed upstream with Mendix

• Mendix support ticket: 278610
• Ticket is the canonical bug report; we attached the full failing
  output, the bundle architecture audit, and the workaround.

Suggestions for mxcli

This is upstream, but mxcli is closest to the user pain. A few options
ranked from cheapest to most invasive:

1. Detect & warn: when running on arch == arm64 and the auto-
   selected mxbuild has an osx-x64/deno that is x86_64 alongside an
   osx-arm64/deno, log a clear warning with a one-liner workaround
   and a link to this issue / Mendix ticket 278610. Saves users the
   half-hour bisect.
2. Document in the docker workflow skill / README: a short
   "Apple Silicon + Studio Pro 11.10.0 Beta" callout pointing at
   --mxbuild-path and the swap commands.
3. Auto-stage a patched mxbuild: mxcli setup mxbuild already
   caches mxbuild at ~/.mxcli/mxbuild/{version}/. When the detected
   Studio Pro mxbuild has this defect, mxcli could clone it into the
   cache and apply the Deno swap automatically, then prefer the cached
   copy over the in-bundle one. Most invasive; most useful.

(1) on its own already prevents the wasted half hour. (3) makes the
experience zero-friction once the detection in (1) exists.

Repro

1. Apple Silicon Mac, macOS 15+.
2. Studio Pro 11.10.0 Beta installed at the default /Applications/
   path.
3. Any Mendix 11.10.0 project that builds clean — we used a
   fresh-from-MyApps project plus a 10-commit demo
   (Foresight-main). mxcli docker check -p <proj>.mpr returns
   0 errors so the project is not the cause.
4. mxcli docker run -p <proj>.mpr → crash as above.

Happy to attach the full log or run extra diagnostics if useful.

[github-actions]

Issue Triage

Summary:
The issue reports that mxcli docker run fails on Apple Silicon Macs because Studio Pro 11.10.0 Beta’s bundled MxBuild launches the x86_64 Deno binary under Rosetta 2, causing a Deno panic and build failure.

Checklist of required bug‑report information

Required info	Present?	Details
mxcli version	✅	v0.10.0‑dirty (2026‑05‑13T20:04:50Z)
Mendix version	✅	11.10.0 (Studio Pro 11.10.0 Beta)
Scenario	✅	mxcli docker run -p Foresight.mpr
Expected output	✅	MxBuild completes, runtime starts in Docker
Experienced output	✅	MxBuild aborts with Deno panic, component‑host timeout, Docker build fails
AI bug report (mxcli diag --bundle or session log)	❌	Not included (only the error output is shown)

What’s missing:
The issue does not contain the output of mxcli diag --bundle (or at least a full session log) that would help diagnose the environment and CLI configuration.

Polite request:
Could you please run mxcli diag --bundle (or share the full session log from the failing command) and attach the resulting bundle or log to the issue? That will give us the complete context needed to investigate further.

Thank you for the detailed report! Once the diagnostic information is added, the issue will be complete.

---

Automated triage via OpenRouter — workflow source

[dimenus]

Diag bundle

Generated mxcli-diag-20260514-114305.tar.gz (12 KB) via:

mxcli diag --bundle -p Foresight.mpr

Contents:

system-info.txt              ← mxcli version, host arch, detected Studio Pro path
logs/mxcli-2026-05-13.log
logs/mxcli-2026-05-14.log    ← captures the full failing docker run session

The 2026-05-14 log includes the Deno panic, MxBuild timeout, and the
final exit status 1. system-info.txt confirms host arch = arm64.

I will drag-drop the tarball into this issue via the web UI in a moment
(the GitHub REST/GraphQL API does not accept binary attachments on
issue comments — they go through user-attachments.githubusercontent.com,
which only the web client can hit).

Happy to re-run with --tail or any specific subcommand if more
detail is needed.

[rsaunderson-i3v]

mxcli-diag-20260514-114305.tar.gz

[dimenus]

Heads-up: a second Studio Pro 11.10.0 Beta packaging bug surfaces once the Deno arch is fixed

Sharing only because it has practical relevance to mxcli users; the
defect itself is fully upstream and is being tracked on Mendix support
ticket 278610.

After applying the Deno arm64 workaround, MxBuild reaches the
ImageExporter.ExportAppIcons step in PAD builds and fails with:

System.IO.FileNotFoundException: Could not load file or assembly
  'Microsoft.macOS, Version=26.2.0.0, …'. The system cannot find the
  file specified.

Root cause: Microsoft.macOS.dll ships at
Contents/modeler/Microsoft.macOS.dll but is not declared in
mxbuild.deps.json, so .NET's TPA list excludes it and
Assembly.Load fails. Studio Pro itself loads the same DLL fine via
its own bootstrap, so the bug is specific to the CLI invocation.

This is not actionable inside mxcli — there is no shim mxcli can
write to fix a missing entry in MxBuild's own deps.json. The only
useful mxcli-side response is detection: surface a clear message
when this specific FileNotFoundException for Microsoft.macOS appears
in mxbuild output, pointing users at Mendix support ticket 278610 and
the "use Studio Pro Run Locally" workaround. Otherwise users will
spend a long time bisecting.

Filing this against mxcli #557 only because every mxcli user on
Apple Silicon + Studio Pro 11.10.0 Beta will hit this combo together.
Full bug details and a repro are in the Mendix ticket.