[Bug]: delegate_task mode "wait" outlasts Cursor's ~60s MCP timeout; the child starts but the parent never gets its taskId

未关闭
  • 哪里不对？
#35,714 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
58/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
node.js, typescript
领域
backend-api-design

调研方向

Start in the apps/server area and trace the delegate_task handler's wait mode, especially how its timeout and result are returned to the MCP client. Reproduce with Cursor using a wait longer than about 60 seconds, then check that the parent receives the task and child thread IDs before the client times out, or that waiting is bounded or made asynchronous. Confirm the child continues running after the parent gets those IDs.

由索引模型根据 Issue 内容生成。

描述

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server

Steps to reproduce
  1. Start a thread on the Cursor provider (seen with gemini-4-carbon).
  2. Have it call delegate_task with mode: "wait" and timeoutMs: 600000 for a task that takes more than about a minute (here, a read-only plan review).
Expected behavior

One of:

  • The call returns before the client's request timeout with the taskId and childThreadId, and the child keeps running.
  • mode: "wait" is capped below the MCP client's request timeout, or turned into async when the client can't wait that long.

The parent can always find out which child it started.

Actual behavior

The child starts, but the parent's tool call fails after about 60 seconds with:

MCP error -32001: Request timed out

That is Cursor's MCP request timeout. The server is still inside its 10-minute wait. The taskId and childThreadId never reach the parent, which sees a failed call. In one thread the Fable child was created at 23:47:47.244Z, and the parent's call failed at 23:48:45.750Z with the child still running.

To recover, the parent called t3_thread_list with includeSubagents: true to find the children it had just started. It then polled t3_thread_wait with a 45-second timeout about 8 times. A model that treated the failure as real could just as easily have started the child again.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Beta) desktop 0.1.8

Environment

macOS 26 (Darwin 25.6), Cursor provider (cursor-agent), parent model gemini-4-carbon; children on Cursor (claude-fable-5-2) and Codex (gpt-6-astra).

Logs or stack traces
delegate_task  mode=wait timeoutMs=600000  title="Fable 5.2 High review of #1901 Core 25 judge benchmark plan"
-> {"message": "MCP error -32001: Request timed out"}
child thread createdAt 2026-11-12T23:47:47.244Z, status running
Workaround

Use mode: "async" from Cursor, and find children with t3_thread_list if a wait call times out.

Related: #30006 (wait mode makes Codex cell harnesses poll every 30s). Same root mismatch: the server-side wait is longer than what the client harness allows for one tool call.

主要语言
TypeScript
星标
24.8k
派生
6.4k
平均合并
59 分钟
30 天内合并 PR
418

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

pingdotgg/t3code 的其他 Issue

查看 pingdotgg/t3code 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。