When using --matlab-session-mode=existing, MCP server should start a MATLAB instance if it doesn't find one

[brianbuechel]

The connection to existing MATLAB session works great if MATLAB is already started. If it isn't, I get the error MATLAB session N is not alive, where N is a number that increments if the agent keeps trying. I think it should start a MATLAB instance if there isn't one already.

[Ebola-Chan-bot]

I can't agree. Very often it was because I forget to do shareMATLABSession in the target session, not that there really isn't one existing. I guess it would be more elegant for you to manually start a new session than for me to have to close an extra one.

[pauldruce]

Hello, thanks for the feedback!
Changing the existing mode to start a new MATLAB when it can't find one would go against the mode's intent. As pointed out, you might have MATLAB open but not yet shared for MCP - silently launching a second instance in that scenario would be confusing.

That said, a new mode (e.g. try existing first, fall back to launching) could be worth exploring.
If that's something you'd find useful, feel free to 👍 this issue and we can gauge community interest.
We will consider this when planning our roadmap. 🙂

[nightfury1802]

built a workaround proxy that handles this + compresses output, feedback welcome
https://github.com/nightfury1802/matlab-mcp-proxy/tree/main

[nightfury1802]

Adding more detail to my earlier comment since this thread has good discussion about the design intent.

Root cause (from reading server logs)

When --matlab-session-mode=existing starts, it immediately tries to connect to the MATLAB Connector at the port written in connector.securePort by the matlab server. It retries every ~2 seconds for up to 30 seconds. The problem: without --initialize-matlab-on-startup=true, the matlab server starts MATLAB lazily — only on the first tool call. So the simulink server's 30-second discovery window expires before MATLAB has even been asked to start.

Claude Code launches
├── matlab server starts (MATLAB not yet running)
└── simulink server starts → polls connector.securePort for 30s → times out ❌

30s later: user calls evaluate_matlab_code → MATLAB starts → too late

Workaround that works reliably

Add --initialize-matlab-on-startup=true to the matlab server's args in ~/.claude.json. MATLAB boots eagerly at Claude Code launch (~15–20s), which falls within the simulink server's 30-second retry window.

Claude Code launches
├── matlab server starts → MATLAB boots immediately (~15-20s)
└── simulink server starts → polls connector.securePort for 30s
    → at ~15-20s: MATLAB ready → session shared → connects ✅

This is consistent with @pauldruce's suggestion about a "try existing, fall back to launching" mode — the intent of existing is preserved, and MATLAB starts reliably within the window.

I documented this investigation and built a proxy that handles session ordering + compresses verbose output (whos tables, repeated warnings, build logs etc.) by 48–66%:
https://github.com/nightfury1802/matlab-mcp-proxy

[github-actions]

This issue has been addressed in v0.10.0. Feel free to reopen the issue if you need. Thank you for your contribution.