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

Đang mở
  • Có gì không ổn?
#35,714 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
backend-api-design

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
24.8k
Fork
6.4k
Merge trung bình
59 phút
Pull request đã merge (30 ngày)
418

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingdotgg/t3code

Tất cả issue của pingdotgg/t3code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.