mxcli init copies Windows binary into project, making devcontainer unusable on Windows

[TOFBuck]

mxcli init copies Windows binary into project, making devcontainer unusable on Windows

Summary

When running mxcli init on Windows, the tool copies the currently running Windows executable (mxcli.exe) into the project root. The generated devcontainer is a Linux environment, so the copied binary is a PE (Windows) executable that cannot run inside the container. The result is that the devcontainer starts up but mxcli is silently non-functional, with no error or warning produced during init to indicate that this has happened.

Environment

• OS: Windows (tested on Windows 11)
• mxcli installed as a native Windows binary
• Devcontainer runtime: Docker Desktop with WSL2 backend
• VS Code with Dev Containers extension

Steps to reproduce

1. Install the Windows release of mxcli from the releases page.
2. Run mxcli init /path/to/my-mendix-project.
3. Open the project folder in VS Code and reopen in the Dev Container.
4. Inside the container, attempt to run ./mxcli --version.

Expected behaviour

mxcli init should place a working mxcli binary in the project root that is executable inside the Linux devcontainer.

Actual behaviour

The binary placed in the project root is the Windows PE executable. Inside the Linux container it either fails to execute with a format error or produces no output at all. The init command gives no warning that the copied binary is incompatible with the container's OS.

Root cause

mxcli init uses os.Executable() (or equivalent) to locate the currently running binary and copies it verbatim into the project root. On Windows, this is a PE-format .exe file. The devcontainer is Linux-based and cannot execute PE binaries, so the copy is immediately unusable.

Workaround

Manually download the correct Linux binary from the releases page and place it in the project root before opening the devcontainer:

curl -L https://github.com/mendixlabs/mxcli/releases/latest/download/mxcli-linux-amd64 -o mxcli
chmod +x mxcli

Suggested fix

During mxcli init, detect when the host OS is Windows and instead of copying the local binary, either:

1. Download the Linux binary automatically from the releases page (matching the current version) and write that to the project root instead. This is the most seamless option for users.
2. Emit a clear warning explaining that the copied binary will not work inside the devcontainer on Windows, and print the curl command needed to get the correct binary. This is the lighter-weight option if automatic downloading is undesirable.

Option 1 could use the GitHub releases API to resolve the correct download URL based on mxcli --version, ensuring the binary in the project always matches the version that generated the config files.

References

This issue is documented in a real-world walkthrough here: https://medium.com/@MohamedElNady27/i-let-an-ai-build-a-full-mendix-app-from-scratch-heres-what-happened-08511dd660b1

[github-actions]

Issue Triage

Summary:
The mxcli init command on Windows copies the Windows PE binary into the project, which cannot run inside a Linux devcontainer, leaving mxcli non‑functional without any warning.

Checklist for bug report completeness

Required info	Present?	Details
mxcli version (output of mxcli --version or commit/build)	❌	Not mentioned
Mendix version of the project (e.g., 10.x, 9.x)	❌	Not mentioned
Scenario – what the user was trying to do	✅	Running mxcli init to set up a project for use in a devcontainer
Expected output – what should have happened	✅	A working mxcli binary usable inside the Linux devcontainer
Experienced output – what actually happened (error, wrong result, crash)	✅	The copied Windows binary fails to run in the Linux container; no warning is shown
AI bug report – output of mxcli diag --bundle or session log	❌	Not provided

Requested information
To help us investigate and fix this issue, could you please add the following details to the issue?

1. The version of mxcli you are using (run mxcli --version and paste the output).
2. The Mendix version of the project you initialized with mxcli init.
3. If possible, run mxcli diag --bundle and attach the resulting bundle (or at least the session log) so we can see the exact environment and command execution.

Thank you for reporting this—your additional details will let us reproduce the problem and implement a proper fix.

---

Automated triage via OpenRouter — workflow source

[TOFBuck]

mxcli version v0.4.0 (2026-04-01T06:49:43Z) 10.24.16 mvg, Dennis de Buck [Afbeelding met Graphics, Amber, cirkel, duisternis Automatisch gegenereerde beschrijving] Dennis de Buck Mendix Consultant +31-6-15215539 ***@***.*** Low Code | Big Data | AI | IoT | RFID

…

________________________________ Van: github-actions[bot] ***@***.***> Verzonden: vrijdag 3 april 2026 16:34 Aan: mendixlabs/mxcli ***@***.***> CC: Dennis de Buck ***@***.***>; Author ***@***.***> Onderwerp: Re: [mendixlabs/mxcli] mxcli init copies Windows binary into project, making devcontainer unusable on Windows (Issue #91) [https://avatars.githubusercontent.com/in/15368?s=20&v=4]github-actions[bot] left a comment (mendixlabs/mxcli#91)<#91 (comment)> Issue Triage Summary: The mxcli init command on Windows copies the Windows PE binary into the project, which cannot run inside a Linux devcontainer, leaving mxcli non‑functional without any warning. Checklist for bug report completeness Required info Present? Details mxcli version (output of mxcli --version or commit/build) ❌ Not mentioned Mendix version of the project (e.g., 10.x, 9.x) ❌ Not mentioned Scenario – what the user was trying to do ✅ Running mxcli init to set up a project for use in a devcontainer Expected output – what should have happened ✅ A working mxcli binary usable inside the Linux devcontainer Experienced output – what actually happened (error, wrong result, crash) ✅ The copied Windows binary fails to run in the Linux container; no warning is shown AI bug report – output of mxcli diag --bundle or session log ❌ Not provided Requested information To help us investigate and fix this issue, could you please add the following details to the issue? 1. The version of mxcli you are using (run mxcli --version and paste the output). 2. The Mendix version of the project you initialized with mxcli init. 3. If possible, run mxcli diag --bundle and attach the resulting bundle (or at least the session log) so we can see the exact environment and command execution. Thank you for reporting this—your additional details will let us reproduce the problem and implement a proper fix.

________________________________ Automated triage via OpenRouter — workflow source<https://github.com/mendixlabs/mxcli/blob/main/.github/workflows/ai-issue-review.yml> — Reply to this email directly, view it on GitHub<#91?email_source=notifications&email_token=BUEZ6E5N4IUIL3SPBIIA46D4T7DW7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJYGM3TGMZUHA32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4183733487>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BUEZ6E6PDFIQZXFOXU5BA7L4T7DW7AVCNFSM6AAAAACXL3MOAGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCOBTG4ZTGNBYG4>. You are receiving this because you authored the thread.Message ID: ***@***.***>