[Bug] execute_task killed at ~60s by MCP client timeout — OpenSpace server is alive and working

[shao-zhijie]

🐛 Bug Description

When calling mcp__openspace__execute_task via MCP, the call is killed at approximately 60 seconds by the MCP client's tool-call timeout, even though OpenSpace's execute_task typically needs 3-5 minutes (per the project's own docs at ~/.openclaw/workspace-yingbot/AGENTS.md).

The OpenSpace server is actually alive and processing the task during the kill — the cancellation is on the MCP client side, not the server side.

🔁 Reproduction Steps

1. Start OpenSpace MCP server (e.g., mcporter start openspace or launchd daemon on 127.0.0.1:8083)
2. From a host agent (e.g., OpenClaw / mcporter client), call mcp__openspace__execute_task with a non-trivial task (e.g., "generate an SVG chart" or "research X")
3. Wait — observe the MCP tool call returns MCP error -32001: Request timed out at ~60s
4. Meanwhile, check OpenSpace server logs (~/OpenSpace/logs/openspace/) — observe that the server is actively processing (e.g., "Step 1/5 → Step 2/5") until the moment of cancellation
5. Result: Task is abandoned mid-execution; output never produced via OpenSpace

✅ Expected Behavior

• execute_task should run to completion (3-5 min typical, scales with max_iterations × tool time)
• The MCP client should respect the documented toolTimeout ≥ 600s requirement (already mentioned in docs)
• If the server takes longer, the MCP client should poll/wait, not kill

❌ Actual Behavior

• MCP error -32001: Request timed out at ~60 seconds
• Server logs show the task was still in Step 1-2 of 5 when killed
• Caller has no way to receive the result

🌍 Environment

• OpenSpace repo: https://github.com/HKUDS/OpenSpace (latest main, commit 228f8f7 "fix: Windows PID check")
• Host agent: OpenClaw + mcporter MCP client
• MCP transport: HTTP at http://127.0.0.1:8083/mcp
• Server health: ✅ healthy (returns HTTP 406 with proper JSON-RPC, indicating MCP-protocol is alive)
• Other OpenSpace MCP tools: ✅ working fine (search_skills, fix_skill, upload_skill all respond quickly)
• Affects both max_iterations=10 and max_iterations=20 (both timeout at ~60s)

💡 Suggested Fix

Either (any one of these would unblock the use case):

1. Document the MCP client timeout requirement clearly in README / docs/AGENTS.md, with example configs for mcporter / OpenClaw (e.g., toolTimeout: 600000 for execute_task)

2. Make execute_task a long-running async tool — return a task ID immediately, and add mcp__openspace__poll_task and mcp__openspace__get_task_result to retrieve the result. This is the cleanest fix and works for any MCP client.

3. Add a streaming variant — mcp__openspace__execute_task_stream that emits progress events over the lifetime of the task. This is more complex but gives real-time visibility.

📋 Workaround Currently in Use

Setting the MCP client's tool-call timeout to ≥ 600 seconds (the value already mentioned in OpenSpace's own documentation) on the consumer side. This is fragile and easy to miss for new users — most default MCP client timeouts are 30-60s.

🔍 Evidence

OpenSpace server log excerpt (during a killed execute_task call for a "generate SVG" task):

[2026-06-12 16:39:23] [ShellAgent] Step 1/5: Processing task
[2026-06-12 16:39:26] Executing bash script locally
[2026-06-12 16:39:26] [ShellAgent] Step 2/5: Processing task
[2026-06-12 16:39:52] Task execution cancelled  ← MCP client 60s timeout fired here

Net effect: every execute_task call from OpenClaw (and likely any other MCP client with default 30-60s timeouts) silently fails. The fallback behavior is to detect the timeout and run locally, which loses all of OpenSpace's auto-skill-selection, auto-evolve, and grounding benefits.

Thanks for the great project — happy to help test a fix!

[shao-zhijie]

Workaround Confirmed: Use subprocess openspace --query to bypass MCP timeout

We've confirmed that OpenSpace's task system works perfectly when invoked via subprocess — only the MCP transport is broken for execute_task.

Workaround

cd ~/OpenSpace  # or any dir with .env
nohup openspace --query "Your task here" \
  --max-iterations 15 \
  --timeout 600 \
  --no-ui \
  --log-level INFO \
  > /tmp/openspace.log 2>&1 < /dev/null &
disown

Key points:

• < /dev/null + disown — detach stdin and process group, so the parent shell can exit without killing it
• --timeout 600 — explicitly set LLM timeout to 10 minutes (not the default 60s)
• Subprocess is NOT killed by MCP client — bypasses the 60s MCP transport timeout entirely

Real-world result (2026-06-12)

We ran a 9+ iteration task (generate SVG medical chart) and OpenSpace:

• Auto-selected the svg-render skill from 71 available
• Iterated 9 times to produce + render the output
• Self-cleaned up and exited cleanly with "Goodbye!"
• Output verified: 32KB SVG + 370KB PNG

Suggested fix in the issue is more relevant than ever

The async-task pattern (execute_task returns task_id, separate poll_task / get_task_result) would be the cleanest long-term solution, since it works for ALL MCP clients, not just those that can configure < /dev/null + disown.

Thanks for the great project!