Why is MATLABWindow.exe spawned when launching MATLAB in batch mode?

When starting MATLAB 2026a in batch mode

matlab.exe -wait -batch "run(some_script.m); exit"

it spawns MATLABWindow.exe.

If the script called uses the parallel toolbox, MATLAB seemingly spawns 3 MATLABWindow.exe instances per worker.

Why is this happening and, most importantly, can it be prevented?

According to the documentation starting MATLAB with the flag '-batch'

• Starts without the desktop
• Does not display the splash screen

Why would we need MATLABWindow.exe in this situation?

[dpb]

Try adding "-noFigureWindows" to the startup command...

[Jeremy]

I added "-noFigureWindows" and it reduced, but did not totally eliminate the MATLABWindow.exe processes.

It would be nice to hear from Mathworks staff about what these processes are and why they are necessary. The amont of bloat in the newest MATLAB versions is ridiculous

[dpb]

[Prepared from some AI generated background on implementation details...dpb]

It appears this is a result of the conversion to the web-centric approach to get to a unified OS and web app code base. For development reasons of legacy code constructs and independence across processes, a standard parallel pool (parpool('Processes')) spawns full, independent background MATLAB processes to serve as workers. The new architecture is based on the Chromium Embedded Framework (CEF) for its background components. Each of these workers creates a browser process, a GPU process, and a utility/renderer process, resulting in the observed three MATLABWindow.exe instances per worker.

If you could use threads, instead of processes, (parpool('Threads')), no new MATLAB processes would be initialized since threads execute inside the existing client process memory space. However, this would require that any and all functions called be thread-safe which may not be possible.

All in all, the conversion appears to be controlled by corporate considertions of development cost and ease over pure performance and efficiency. This is understandable from a business perspective but leaves the user fighting with the end result. It's yet to be seen if there is any way they can over time optimize away some of the most overhead intensive areas or just rely on faster and faster CPUs and more memory to overcome the inefficiences.

[dpb]

The MathWorks blog link https://blogs.mathworks.com/matlab/2025/05/16/whats-with-all-the-big-changes-in-r2025a/ if you haven't seen it is the internal viewpoint of what they've done and the rationale for it. It doesn't address any of the user downside, only what it does from their implementation viewpoint.