Summary
When invoke_expression times out, the response reports that the pipeline is still running and tells the client to call wait_for_completion.
That background-execution model is reasonable, but the timeout response currently omits output that the running command may already have produced before the timeout fired.
Why this matters
- It makes long-running command diagnosis harder for the MCP client.
- It hides useful clues when a command unexpectedly enters watch mode.
- It hides useful clues when a command is waiting for interactive input.
wait_for_completion only helps after the command finishes; it does not help explain what the still-running command is doing now.
In the shared-console model, a human watching the terminal can often see that output, but the MCP client cannot. That reduces autonomous troubleshooting value.
Real example
A real case was:
Set-Location web
pnpm test -- --run src/api/client.logs.test.ts src/api/client.stats.test.ts src/hooks/useLogs.test.tsx src/hooks/useStats.test.tsx
This actually launched Vitest in watch mode, printed the normal test output, and ended with PASS Waiting for file changes....
From the shared terminal, a human can immediately see that the command is not stuck and has entered watch mode. From the MCP timeout response, the client only sees that the pipeline is still running, without the output that explains why.
Repro
Run a command that emits output incrementally and then keeps running past the timeout:
1..5 | ForEach-Object {
Write-Output "tick $_"
Start-Sleep -Seconds 2
}Call invoke_expression with timeout_seconds=3.
Actual
The timeout response says the pipeline is still running and instructs the client to use wait_for_completion, but it does not include the output already produced before timeout.
Expected
The timeout response should include buffered information output produced so far by the current running pipeline.
If full streaming is too large a change, even a truncated partial snapshot at timeout would be a meaningful improvement.
Summary
When
invoke_expressiontimes out, the response reports that the pipeline is still running and tells the client to callwait_for_completion.That background-execution model is reasonable, but the timeout response currently omits output that the running command may already have produced before the timeout fired.
Why this matters
wait_for_completiononly helps after the command finishes; it does not help explain what the still-running command is doing now.In the shared-console model, a human watching the terminal can often see that output, but the MCP client cannot. That reduces autonomous troubleshooting value.
Real example
A real case was:
This actually launched Vitest in watch mode, printed the normal test output, and ended with
PASS Waiting for file changes....From the shared terminal, a human can immediately see that the command is not stuck and has entered watch mode. From the MCP timeout response, the client only sees that the pipeline is still running, without the output that explains why.
Repro
Run a command that emits output incrementally and then keeps running past the timeout:
Call
invoke_expressionwithtimeout_seconds=3.Actual
The timeout response says the pipeline is still running and instructs the client to use
wait_for_completion, but it does not include the output already produced before timeout.Expected
The timeout response should include buffered information output produced so far by the current running pipeline.
If full streaming is too large a change, even a truncated partial snapshot at timeout would be a meaningful improvement.