start_process timeout_ms parameter silently capped at 60s by MCP transport (DC v0.2.39)

[JesperLive]

Summary

start_process's timeout_ms parameter is silently ignored above a hard 60-second ceiling. Setting timeout_ms: 90000 (90s) does not extend the timeout — the call still terminates at exactly 60s with MCP server "Desktop Commander" tool "start_process" timed out after 60s.

This is either a bug (the schema says timeout_ms is configurable) or a documentation gap (the 60s cap should be in the schema).

Reproduction

Invocation:

{
  "command": "Get-Date; Start-Sleep -Seconds 70; Get-Date; Write-Host AFTER-70S",
  "timeout_ms": 90000
}

Result after exactly 60s:

MCP server "Desktop Commander" tool "start_process" timed out after 60s

The timeout_ms: 90000 value was set but the call still hit the 60s ceiling. The process was running successfully — Start-Sleep -Seconds 70 doesn't fail, the timeout came from the MCP transport layer.

Tried timeout_ms: 120000 and timeout_ms: 300000 — same 60s cap.

Schema description

timeout_ms (number)

— no documented upper bound. The schema implies the user can set any value.

Impact

Long-running operations (large luacheck scans, big git operations, dataset processing) cannot use start_process directly. Users have to either:

1. Wrap commands in a script that writes output to a file and read the file later
2. Use start_process to launch a script and read_process_output repeatedly to keep the connection alive

Both are workable but require workarounds the schema doesn't hint at.

Suggested fix

Either:

1. Honor the parameter — let timeout_ms actually control the timeout up to some larger ceiling (5 minutes? 10 minutes?), with the MCP transport keeping the connection alive via heartbeat or chunked progress.

2. Document the cap — add to the schema description: "Note: the MCP transport enforces a 60s ceiling regardless of timeout_ms. For longer commands, write output to a file and read it via read_file afterwards, or use read_process_output to poll a long-running process."

The second option is much cheaper and would already prevent the surprise.

Environment

• DC version: 0.2.39
• OS: Windows 11, system Node 25.9.0
• Default shell: powershell.exe (PS 5.1.26100.8115)

Workaround

A wrapper that streams to both console and a file in %TEMP%. The file survives even if MCP times out. But this is a separate tool — DC users would benefit from either of the fixes above.