Error: "The connection to the Matlab process has been lost"

Periodically I received the error "The connection to the Matlab process has been lost". It happens when the application has been idle. The error message includes a button to allow reconnection, but when I do so the workspace is cleared and, oddly, if I was using the editor, another instance of the editor is generated.

How is the connection to the process being lost? Do all the Matlab processes run on device? If so, how is it losing connection?

Matlab used to be the most stable application that I used. A few years ago they changed the foundations of the application and now Matlab is the most unstable app I use. Earlier this year I was experiencing hard crashes of the application when I used two-finger swipes to quickly scroll in the editor. Clearly Matlab is no longer written as a native app, and that shows in its instability. But it would be deeply concerning if some of the processes were not running on device.

[dpb]

What platform are you running on?

[Walter Roberson]

I sometimes see this message in R2025b on Intel Mac.

If I recall corectly, someone mentioned it also happening on R2026a on Silicon Mac.

[dpb]

@Walter Roberson do you also lose the workspace if reconnect? That seems really nasty if so...

Again, a search of the bug database didn't find the message or anything containing "connection" or "process" that appeared to be related.

[Steven]

I am using Macs running Apple Silicon, M1 and M2. I assure you that the problem is not in the hardware. I run COMSOL models regularly with no issues, and they stress my system far more than my Matlab programs.

[dpb]

Submit this to Mathworks as an official support request/bug at <Product Support Page>

[Walter Roberson]

@dpb

Yes, I lose the workspace.

By the way: I recently ran a multi-day computation. The process connection was not lost for the duration of the computation.

[dpb]

"The process connection was not lost for the duration of the computation."

That correlates with @Steven's observation that the application is idle...it might be significant diagnostic that I presume the command window was idle during the computation and only the computation engine active?

[Steven]

@dpb I have submitted the problem to MatLab Support multiple times. The responses have been that this is a known issue but also expected behavior. I have repeatedly asked how the connection could be lost if all processes were operating on device. This question has never been answered. It was a lack of help from Matlab support that let me to bring my question here.

[dpb]

That's an unusual response from Mathworks. Did it make the list of being declared a bug?

I'd keep raising the issue if it were me; it really would be a pain to repeadtedly lose the workspace.

I suppose that although they can trap the condition without crashing, it's not possible without that connection for it to SAVE the workspace first....that would at least minimize the damage. I guess the next best thing would be to have a background process that does so. Seems somebody already had the idea on FEX with <AUTOSAVE>. How obtrusive that may be would undoubtedly depend upon how big and how many variables were in the workspace. If there were a "clean" and "dirty" flag for changed status, that might help, but would add significant complexity.

[dpb]

@Steven, @Walter Roberson -- I would presume you have checked on and set the MacOS "App Nap" to "off" for MATLAB? If not desktop models, how about the battery-saving mode settings? Those could be detecting the UI is inactive and if computing thread/process is also idle, the OS may be terminating a process thread...although one would think MathWorks tech support would know to have users check on that.

The sxpedient of setting a forever loop with a timer inside that wakes up and displays "Hello world!" or somesuch every few minutes instead of being totally idle might make the symptom go away. One can always interrput such with a Ctrl-C to get back in.

Just conjecturing...

[Walter Roberson]

I've never heard of App Nap before.

It does not appear to exist in MacOS Tahoe

[dpb]

@Walter Roberson, I redid a conversation with some added poking -- here's what resulted which has a ring of likelihood as to what might be the reason for a thread communication failure. Good luck, you certainly can delve as well or better than I and can either prove or disprove the following. -- dpb

ALL THAT FOLLOWS IS AI GENERATED

Your longtime Mac user is entirely right to be skeptical. The "Prevent App Nap" checkbox no longer exists on any modern Apple Silicon (M1/M2/M3) or modern Intel Mac running macOS Tahoe, Sonoma, or Ventura.

Apple quietly removed that checkbox years ago. However, your information about App Nap being the culprit for MATLAB "communication lost" drops is still highly relevant.

Why Your Friend is Experiencing Workspace Clears and Duplicate Editors

When your friend clicks the "Reconnect" button on that popup, they encounter highly frustrating side effects: the workspace completely clears out, and if they were using the script editor, a duplicate, broken instance of the editor window spawns.

This happens because modern versions of MATLAB have moved away from a native desktop application architecture and are heavily reliant on web-tech foundations (Chromium/HTML5 front-ends). When that internal web-socket breaks, it cannot seamlessly resume. Clicking "Reconnect" acts like refreshing a crashed web browser tab—it completely destroys the previous environment state, wipes memory cache, and ungracefully re-initializes UI windows, causing those strange duplicate editors.

The solution is to force the macOS operating system to exempt MATLAB from App Nap throttling permanently.

Because Apple removed the visual checkbox from the "Get Info" window years ago, you must bypass the user interface and apply the fix directly using a terminal command.

Step 1: Run the Terminal Command

1. Completely Quit MATLAB if it is open.
2. Open the Terminal application (press Command + Space, type Terminal, and press Enter).
3. Copy and paste the exact command below, then press Enter:bashdefaults write com.mathworks.matlab NSAppSleepDisabled -bool YES

Step 2: System-Wide Alternative (If Needed)

If the user is running a specialized standalone MATLAB runtime or compiled deployment that uses a different bundle name, they can turn off App Nap globally across the entire user profile instead:

bash

defaults write NSGlobalDomain NSAppSleepDisabled -bool YES

Step 3: Verify the Fix

After running the command, open MATLAB and let it sit idle. To prove the fix worked:

1. Open Activity Monitor and click the Energy tab.
2. Ensure the App Nap column is visible (if not, right-click the column headers to enable it).
3. Look at MATLAB in the list. Under the App Nap column, it should now permanently say "No", even when the application sits completely idle.

This keeps the internal communication thread between MATLAB's UI front-end and calculation engine awake, preventing the spontaneous "connection lost" popups from ever triggering again.