Automations: cloud runs die mid-thinking and never complete the job (also falsely report SUCCEEDED)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Production Automations no longer complete their work. Cloud runs die mid-thinking (transcript ends mid-word, e.g. “Let”, “Fall”, “The…”), often before any tools run — or mid-pipeline after some tools already succeeded. The prompted job is left unfinished.

The platform still marks these runs as SUCCEEDED / FINISHED, so failures are easy to miss. Slack MCP can show SKIPPED when the agent dies before tool use.

Not a missing-secrets issue (credentials bootstrap succeeds on good short runs). On-demand budget was not exhausted. Reproduced with kimi-k3-max and glm-5.2-max — switching models did not fix it.

Fresh failing runs below were captured with Privacy Mode disabled (Share Data) on this Automations account so logs should be readable.

Steps to Reproduce

  1. Ultra account with Automations enabled; Slack- or cron-triggered Automation with Slack MCP.
  2. Use model kimi-k3-max (also reproduced with glm-5.2-max).
  3. Trigger a multi-step Automation prompt (tools required).
  4. Observe: thinking starts, then stops mid-word; tools may never run or stop mid-pipeline; status becomes SUCCEEDED/FINISHED anyway.

Control: a very short diagnose canary (~30–40s) on the same account can still complete (bc-b833e42c-… below). Normal Automation work does not reliably finish.

Expected Behavior

Automation runs must finish the prompted work end-to-end. If the session is truncated mid-thinking, that must be a hard failure (not SUCCEEDED), with a clear error and a way to retry.

Operating System

Other

Version Information

N/A — Cloud Automations / Background Agents (not IDE-local). Account owns the bc- IDs below.

For AI issues: which model did you use?

kimi-k3-max (primary); also glm-5.2-max

For AI issues: add Request ID with privacy disabled

Privacy Mode disabled (Share Data) for these failing repros:

bc-668ece78-19bf-54d5-8ac4-716677943c6a
bc-cdb212ec-1688-51e5-83bb-e959b0e50fe2

Earlier same-day IDs (may have been under Privacy Mode; still useful for pattern):

bc-b833e42c-638b-5b09-9c44-420763d0952f
bc-6da5410c-4919-5ea2-808a-e2ba708a5d0f
bc-4d7b15ae-eef0-55e1-a214-b72afc10524a
bc-175f4c86-9225-58a8-b6aa-c0a9f8711f31
bc-10bb661a-d281-5918-b47f-81831d054bc5
bc-350250de-8931-4619-b635-5c07900bbbc8
bc-b45319f2-244c-4b10-b4a8-24d0de11b0c0
bc-d4fb7bf5-9589-501c-893a-691fbef05140
bc-f05eb9d0-3e41-4eee-a357-972f07a93358

Additional Information

Date: 2026-08-14. Same Automations account for all IDs.

Privacy-off failing repros (please inspect these first):

  • kimi-k3-max: bc-668ece78-19bf-54d5-8ac4-716677943c6a (~9m, tools + Slack start message ran, aborted mid-thinking at “Fall”, status SUCCEEDED, job unfinished)
  • glm-5.2-max: bc-cdb212ec-1688-51e5-83bb-e959b0e50fe2 (~32s, thinking=“Let”, Slack MCP SKIPPED, status SUCCEEDED)

Control that worked earlier: bc-b833e42c-638b-5b09-9c44-420763d0952f (short diagnose canary).

This report is posted from our dedicated Automations / ops account (owns these bc- runs) so logs can be matched. If you need a human contact, personal email, or repo details, please say so in-thread or email us, we monitor that inbox and can share privately.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Update: This looks fixed on our side since Saturday (2026-08-15). Automations on the same account are completing end-to-end again — no mid-thinking truncation and no false SUCCEEDED status. We’ll keep monitoring and reopen with new bc- IDs if it returns.