Agent-mode session silently drops mid-turn after tool_result on unattended Mac (WarmLifecycle idle_timeout suspected)

Open 💬 0 comments Opened Jul 2, 2026 by Jaxxdprime

Summary

On an always-on, mostly-unattended Mac mini running multiple desktop-app agent sessions (local agent mode / CCD), sessions silently die mid-turn immediately after a tool_result — the assistant's next completion is never requested. No error is shown in the UI (turn just ends at the spinner), nothing is written to the session transcript after the tool_result, and main.log has zero lines at the stall timestamp.

Environment

  • Claude desktop app 1.17377.2, claude-code harness 2.1.197
  • macOS (Darwin 25.x), M4 Pro Mac mini, always-on, App Nap disabled for the app (NSAppSleepDisabled=1), pmset sleep=0/displaysleep=0
  • Multiple concurrent agent sessions, some using ScheduleWakeup loops; bypassPermissions; Fable 5 + ultracode

Evidence signature (reproduced repeatedly)

  1. Session transcript (~/.claude/projects/*/<id>.jsonl) ends with a tool_result — in several cases a tool_use_error (e.g. "File has not been read yet") — followed by no assistant events at all.
  2. ~/Library/Logs/Claude/main.log: no entries at the stall moment; nearby entries show [WarmLifecycle:session] Idle timeout reached, disconnecting <session> / [CCD] Pausing session <session> (idle_timeout) — suggesting session-lifecycle suspension racing an in-flight turn.
  3. Persists across: app restart, brand-new chats, and a full OS reboot.
  4. Watched vs unwatched discriminator: with the window frontmost and the user present, a 5-round stress prompt (including two deliberate tool errors + promise-then-deliver) completed 5/5 with no drop. All organic failures occurred while the session was unwatched. (Unwatched repeat of the same test run as well.)

Impact

Unattended/automation-oriented agent sessions on a secondary machine can't be trusted to finish a turn; the failure is silent (looks identical to a completed turn or a sleeping loop).

Workarounds found

  • An armed ScheduleWakeup re-invokes the session and it resumes from context (we tightened loops to 10 min as self-healing).
  • Any new user message revives the session instantly.
  • Keeping the window frontmost appears to avoid it.

Ask

Is WarmLifecycle/CCD idle handling able to suspend a session with an in-flight turn (tool_result received, next completion not yet requested)? If so, could in-flight turns be excluded from idle_timeout, or the drop at least surfaced as a visible error event in the transcript?

View original on GitHub ↗