start_process blocks Electron main thread causing Claude Desktop crashes

[Voork1144]

Problem

When start_process is called with a large timeout_ms value (e.g., 120000ms for long-running tests), the function blocks the Node.js event loop until either:

• A prompt pattern is detected
• The process exits
• The timeout expires

If the spawned process doesn't output recognizable prompts (like >>>, $, etc.), Desktop Commander blocks for the entire timeout duration. This freezes the Electron IPC channel, causing the Claude Desktop webview to become unresponsive and crash.

Evidence from Claude Desktop logs

2026-01-18 10:15:59 [info] start_process called with timeout_ms=120000
2026-01-18 10:17:49 [info] Main webview is unresponsive, will kill and reload
2026-01-18 10:17:50 [error] Sentry caught: { value: 'Main webview became unresponsive' }
2026-01-18 10:17:59 [info] Desktop Commander finally responds (2 minutes later)

The process spawned was a Python test script that didn't output prompt-like patterns, so Desktop Commander waited the full 2 minutes.

Root Cause

In terminal-manager.js, the executeCommand function's timeout is directly controlled by the user-provided timeoutMs:

// Timeout fallback
setTimeout(() => {
    session.isBlocked = true;
    exitReason = 'timeout';
    resolveOnce({...});
}, timeoutMs);  // <-- Can be arbitrarily large!

Suggested Fix

Cap the initial wait time regardless of user timeout. The user can still poll with read_process_output for long-running processes:

// Timeout fallback - cap initial wait to prevent blocking
const MAX_INITIAL_WAIT_MS = 10000; // 10 seconds max
const effectiveTimeout = Math.min(timeoutMs, MAX_INITIAL_WAIT_MS);
setTimeout(() => {
    session.isBlocked = true;
    exitReason = 'timeout';
    resolveOnce({...});
}, effectiveTimeout);

This way:

• start_process returns quickly with isBlocked: true
• Users poll with read_process_output for actual output
• Claude Desktop webview doesn't freeze

Workaround

Until fixed, users should:

1. Use small timeouts: start_process(command, timeout_ms=5000)
2. Poll separately: read_process_output(pid, timeout_ms=30000)

Environment

• Desktop Commander: 0.2.29
• Claude Desktop: 1.1.351
• OS: Windows 11
• Node.js: Built-in Claude Desktop node

[wonderwhy-er]

Hm, but it should not be the case in that sense.
MCPs are in separate process that should not block main Claude UI.

Plus, its not that there is endless while loop.

Problem with Claude loosing chat is old and I seen it happen without DC MCP installed.

Though from their log:
2026-01-18 10:17:50 [error] Sentry caught: { value: 'Main webview became unresponsive' }

That part is interesting.

[sageriverswellness]

well.... I have been trying to figure out why claude desktop is doing EXACTLY what this person is talking about for the last day and a half to 2 days and this is a little coincidental that I am having this exact issue and the only extension that is acting funny also happens to be desktop commander....

[wonderwhy-er]

Well, we actually had smaller timeouts before, sadly in Claude that results in making many read_process_output
And then Claude still crashes out.
Reason is how much work is done inside of one response, not how long individual tool respond.
It still crashes weather they are long or short individually.

So, suggested fix from Voork1144 would not help here.

Basically it works like this

1 Claude app starts new chat message
2 Stream starts and gets to a tool call and waits for tool call
3 Client gets tool call and sends to MCP
4. MCP may take time with long running task or return fast
5. Tool call result sent back to Antropic servers
6. Model streams response further until new tool call and it repeats until AI decided that its done

For all that time something like a stream connection is held with Antropic server.
But when Claude is finicky, often when there is load on their servers, that stream disconnects before finsihing.

Problem is, that Claude does not reconnect, and sometimes even looses whole chat sequence including tool calls.

Sadly we can not change that from our side and weather individual tools are fast or slow responding does not change that if whole message stream is long with many tools calls in one.

Are you guys installing trough npx or trough Claude extension?
For npx I can make alpha build for you to try that has those faster returns. We had them work like that half a year ago but changed than, and it was crashing before and after that change. Change was rather made to conserve tokens in situations where task is long running.