[BUG] Scheduled task (trigger) never completes Gmail send/draft actions — stuck in PENDING indefinitely (7/7 failures)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Resumen

Un trigger recurrente diseñado para generar y enviar por correo un reporte diario (HTML embebido en el cuerpo del mensaje, sin adjuntos) se queda atascado indefinidamente en estado PENDING cada vez que se dispara, sin enviar el correo, sin reportar un error, y sin terminar. Esto ha ocurrido en 7 de 7 intentos consecutivos, usando dos objetos de trigger distintos y tres arquitecturas de prueba diferentes, incluyendo pruebas mínimas que no dependen de ningún sistema externo (ni Bitrix24 ni Google Drive).

Un segundo trigger, casi idéntico en arquitectura (mismo patrón de entrega vía Google Drive + Gmail send_message con HTML grande en el cuerpo), funciona de forma consistente y correcta, lo cual descarta que el problema sea de la cuenta de Gmail, de permisos, o de la arquitectura general de "HTML en el cuerpo del correo".

Impacto

El reporte diario de llamadas ("Reporte de Llamadas") no puede automatizarse actualmente. El trigger fue creado, verificado en modo de prueba repetidamente, y nunca llegó a enviar un solo correo de prueba, por lo que permanece desactivado (enabled: false) a la espera de que este problema se resuelva.

Triggers involucrados

• Reporte Llamadas diario (original): trig_01Pe7Q4oR3FBgh5QYuwAzReb — eliminado durante el diagnóstico (para descartar corrupción del objeto) — 3/3 pruebas atascadas en PENDING
• Reporte Llamadas diario (recreado desde cero): trig_01GCJaFEV1VYTTUjpxsxUgFC — existe, enabled: false — 4/4 pruebas atascadas en PENDING
• Reporte WhatsApp diario (control, funciona bien): trig_014c1grGRJb2zW7v85r2AvNP — existe, enabled: true, en producción — prueba exitosa, activado sin problemas

Cronología detallada de los 7 intentos fallidos

Todos los intentos fueron disparados manualmente vía fire_trigger en modo de prueba ("MODO PRUEBA"), que limita el envío únicamente a mi propio correo. En todos los casos se esperó un mínimo de 7–30+ minutos y se confirmó, vía list_triggers, que last_run.status permanecía en ROUTINE_RUN_STATUS_PENDING sin finished_at, y vía búsqueda en Gmail que ningún correo o borrador nuevo había sido creado.

1. Intento 1 — trigger trig_01Pe7Q4oR3FBgh5QYuwAzReb, FECHA=2026-09-16, fired ~19:49:38Z. Reporte completo (Bitrix + HTML real). Atascado 30+ min.
2. Intento 2 — mismo trigger, FECHA=2026-09-15, fired 20:32:00Z. Reporte completo. Atascado 30+ min.

Diagnóstico intermedio: se ejecutó el script Python (bitrix_llamadas_html.py, mismo webhook de Bitrix24, mismos datos) directamente en un shell, fuera del sistema de triggers. Completó en 13.7 segundos, con datos correctos (548 llamadas totales) y un HTML válido de 27,665 caracteres. Inspección carácter por carácter del HTML confirmó ausencia de caracteres de control, nulls, o codificación problemática (único carácter no-ASCII: "ñ"). Esto descartó el script, los datos de Bitrix24 y la codificación del HTML como causa.

1. Intento 3 — mismo trigger, tras simplificar el texto del paso de envío de correo del prompt y agregar notas anti-reintento, FECHA=2026-09-14, fired 21:14:31Z. Atascado, sin correo. Descarta el texto/wording del prompt como causa.
2. Intento 4 — trigger nuevo creado desde cero, trig_01GCJaFEV1VYTTUjpxsxUgFC (mismo prompt, mismo cron, mismo modelo), FECHA=2026-09-17, fired 21:30:45Z, session cse_01FNQpm7UeD9n5ADKLrQGgP1. Atascado, sin correo. Descarta corrupción o estado específico del objeto trigger original.
3. Intento 5 — mismo trigger nuevo, sin ningún cambio, FECHA=2026-09-18, fired 22:57:27Z, session cse_01VMBb58FyqkstXphNgxDvVL. Atascado, sin correo. Descarta que fuera un fallo intermitente/transitorio simple.
4. Intento 6 — Diagnóstico "HTML mínimo" — mismo trigger. Se sobrescribió la instrucción del disparo para que la sesión disparada ignorara por completo los pasos de Bitrix24 y Google Drive, y únicamente intentara Gmail send_message con un HTML minúsculo (2 párrafos, sin datos reales). Fired 23:15:27Z, session cse_016dzg5nV7Tfu6bVRBm6e2oj. Atascado igual, sin correo alguno. Esto descarta el tamaño del HTML/payload como causa — ni siquiera un correo trivial se pudo enviar.
5. Intento 7 — Diagnóstico "create_draft" — mismo trigger. Instrucción sobrescrita para usar Gmail create_draft (crear borrador, no enviar) en vez de send_message, con el mismo HTML pequeño. Fired 23:46:25Z, session cse_017sSAPM8MypmRJotJsYbrkD. Atascado igual; no se creó ningún borrador (se verificó contra la lista completa de borradores de la cuenta, el más reciente era de febrero de 2026). Esto descarta que el problema sea específico de la acción "enviar" — ninguna acción de escritura en Gmail se completa dentro de este trigger, sea cual sea.

Caso de control que sí funciona

El trigger trig_014c1grGRJb2zW7v85r2AvNP ("Reporte WhatsApp diario") usa la misma arquitectura general: script en Google Drive descargado por la sesión disparada, generación de HTML, y Gmail send_message con el HTML completo (varios miles de caracteres) embebido en htmlBody. Se probó en modo de prueba (FECHA=2026-09-17, fired 19:49:28Z, session cse_01YBbPDkP63jvAsPbqbMxBM6) y completó exitosamente en ~4 minutos (SUCCEEDED), con el correo de prueba confirmado recibido en Gmail. Este trigger ya está activo en producción sin incidentes.

Esto es clave: descarta que el problema sea de la cuenta de Gmail en general, de permisos, de la conexión MCP de Gmail, o de la arquitectura de "HTML grande en el cuerpo del correo" como concepto — el mismo patrón funciona perfectamente en un trigger casi idéntico.

Qué se descartó (con evidencia)

• El script Python y los datos de Bitrix24 (ejecución directa exitosa en 13.7s)
• Codificación/caracteres especiales del HTML generado (inspección carácter por carácter)
• El texto/wording del prompt del trigger (se simplificó, sin cambio de resultado)
• Corrupción o estado específico de un objeto trigger (se recreó desde cero, mismo resultado)
• El tamaño del contenido HTML (un HTML de 2 párrafos falla igual que uno de 27,000+ caracteres)
• La acción específica send_message (se probó create_draft, mismo resultado)
• Webhook de Bitrix24 saturado/lento (las llamadas del script tienen timeout de 30s + 1 reintento; un problema de webhook produciría un error explícito en <60s, no un colgado indefinido; además las pruebas 6 y 7 ni siquiera tocan Bitrix24)
• Problema general de la cuenta de Gmail o de la conexión MCP de Gmail (el trigger de WhatsApp, con arquitectura equivalente, funciona de forma consistente)

Lo que no se pudo diagnosticar desde el lado del usuario

No hay acceso al transcript ni a los logs internos de las sesiones disparadas por estos triggers, por lo que no se puede ver en qué paso exacto se detiene la ejecución dentro de la sesión (cse_...), ni si hay algún error interno que no se refleja en last_run.status. Todo lo anterior se dedujo por eliminación, comparando resultados entre variantes controladas.

Solicitud

Se solicita revisar los logs internos de las 7 sesiones disparadas listadas arriba (en particular las más recientes y minimalistas: cse_016dzg5nV7Tfu6bVRBm6e2oj y cse_017sSAPM8MypmRJotJsYbrkD) para identificar en qué paso se detiene la ejecución y por qué nunca transiciona a SUCCEEDED, FAILED, ni ningún estado terminal. También sería útil confirmar si hay algo particular en la configuración de este trigger (trig_01GCJaFEV1VYTTUjpxsxUgFC) que explique el colgado sistemático, y si existe un timeout máximo esperado para una tarea programada — actualmente last_run.status permanece en PENDING sin finished_at incluso después de 30+ minutos, en vez de marcar la ejecución como fallida por timeout.

What Should Happen?

El trigger debería completar su ejecución y transicionar a un estado terminal (SUCCEEDED o FAILED), no quedarse indefinidamente en PENDING.

En modo de prueba, se esperaría que la sesión disparada complete el envío del correo (o la creación del borrador) vía Gmail en cuestión de segundos a un par de minutos — como sí ocurre consistentemente en un trigger casi idéntico (Reporte WhatsApp, trig_014c1grGRJb2zW7v85r2AvNP), que se completa en ~4 minutos.

Si algo falla (por ejemplo, un límite de tiempo excedido, un error de la herramienta de Gmail, o cualquier otro problema), se esperaría que el trigger transicione a un estado de fallo explícito (FAILED) con un motivo de error, en vez de quedarse silenciosamente en PENDING sin finished_at por más de 30 minutos.

Error Messages/Logs

No se produjo ningún mensaje de error visible. Ese es justamente el problema: la sesión disparada no falla con un error explícito, simplemente nunca termina.

Lo único observable desde fuera es el resultado de list_triggers, que en cada uno de los 7 intentos mostró:

"last_run": {
  "status": "ROUTINE_RUN_STATUS_PENDING",
  "fired_at": "<timestamp del disparo>",
  "session_id": "<cse_...>",
  "failure_reason": "ROUTINE_RUN_FAILURE_REASON_UNSPECIFIED"
}

Sin campo finished_at, incluso 30+ minutos después del disparo. failure_reason siempre queda "UNSPECIFIED" (no vacío/nulo, pero tampoco indica un motivo real), y el estado nunca transiciona a SUCCEEDED ni a FAILED.

No tengo acceso al transcript ni a los logs internos de la sesión disparada (cse_...), por lo que no puedo ver si ahí ocurre algún error interno antes de quedarse colgada. Sería muy útil que alguien con acceso a esos logs revise específicamente las sesiones cse_016dzg5nV7Tfu6bVRBm6e2oj y cse_017sSAPM8MypmRJotJsYbrkD (las pruebas mínimas, sin dependencias externas) para ver en qué paso se detiene exactamente.

Steps to Reproduce

1. Crear una tarea programada (trigger) en Claude Code Remote cuyo prompt incluya, entre otros pasos, una llamada a la herramienta Gmail send_message (o create_draft) con contenido HTML en el cuerpo del correo.
2. Disparar el trigger manualmente con fire_trigger (en este caso usando un texto adicional de "MODO PRUEBA" para limitar el envío a una sola cuenta de prueba).
3. Monitorear el estado con list_triggers: last_run.status queda en ROUTINE_RUN_STATUS_PENDING, sin finished_at, indefinidamente (se esperó 30+ minutos en varios intentos).
4. Verificar en Gmail (search_threads / list_drafts) que ningún correo ni borrador nuevo fue creado.

Esto se reprodujo de forma consistente en 7 de 7 intentos, variando lo siguiente para aislar la causa:

• Dos objetos de trigger distintos (uno original, otro recreado desde cero).
• Contenido HTML real y completo (~27,000 caracteres) generado desde datos externos (Bitrix24 vía webhook).
• Contenido HTML mínimo (2 párrafos), sin tocar ningún sistema externo — mismo resultado (atascado).
• La herramienta Gmail send_message y, por separado, Gmail create_draft — mismo resultado con ambas.

Un trigger casi idéntico en arquitectura (mismo patrón: script en Google Drive + Gmail send_message con HTML grande en el cuerpo) NO reproduce el problema — se completa exitosamente en ~4 minutos de forma consistente. IDs de sesión de las pruebas más reveladoras (mínimas, sin dependencias externas): cse_016dzg5nV7Tfu6bVRBm6e2oj (send_message con HTML mínimo) y cse_017sSAPM8MypmRJotJsYbrkD (create_draft con HTML mínimo).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

No aplica — no estoy usando el CLI de Claude Code en terminal. Estoy usando Claude Cowork (app de escritorio) con tareas programadas ("scheduled tasks" / triggers) vía Claude Code Remote, que es el producto/superficie donde ocurre este bug.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_