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

Abierto
  • ¿Algo no está bien?
#35,714 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
backend-api-design

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
59 min
PR fusionados (30 d)
418

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.