Cross-session messages to idle desktop-app sessions never start a turn — ~38 parallel count_tokens requests, then nothing (app build 1.32352.1)

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Aug 18, 2026

Summary

Since desktop app build 1.32352.1 (auto-installed 2026-08-18 00:14 EDT), sending a
message to an idle desktop-app-managed session (session-management send_message, or
cross-session SendMessage) delivers the message into the target's transcript and flips the
session to "running" — but no turn ever starts: zero events are emitted, the model is
never invoked, and after ~16 minutes the session dies with *"The session stopped
responding. Send your message again to resume with a fresh process."* On that resume, the
triggering message is dropped from the session's working context (the event log
retains it; the model has no memory of it).

Attended prompts (typing in the session's window) work perfectly on the same sessions
throughout. Before the 00:14 update, the same unattended flow worked (three successful
message-triggered resumptions 23:45–23:56 the same night).

Debug capture (the smoking gun)

With /debug enabled on a target session, an incoming unattended message produced:

  • ~38 parallel POST /v1/messages/count_tokens requests within ~400 ms of arrival

(13:07:31.888–13:07:32.274 in the log)

  • **no API responses logged for them, and no /v1/messages generation request ever

issued**

  • 30s later: [skills] idle — switching poll interval to 30000ms — session returns to

idle while externally still marked busy

Attended turns in the same session minutes earlier show healthy round-trips (first byte
4.5s/1.4s), tool dispatches outcome=ok, zero [ERROR]/[WARN].

Also observed (possibly related)

[DEBUG] Hooks: Found 0 total hooks in registry in these sessions
(cc_entrypoint=claude-desktop, Agent SDK; log notes "Fast mode is not available in the
Agent SDK") despite six hooks declared across user and project settings — SessionStart /
Stop / UserPromptSubmit / PostToolUse never load or fire on this entrypoint. CLI-entrypoint
sessions on the same machine load and fire the same hooks correctly.

Environment

  • Desktop app build 1.32352.1, macOS (darwin-arm64), installed 2026-08-18 00:14:06 —

failure onset matches install time to the minute; no newer app build available

  • Reproduced identically under CLI 2.1.220 and 2.1.234 (native install)
  • 100% reproduction since onset: heavy (800+ msg) and light sessions, solo and

concurrent, across process kills and a full harness restart

  • Ruled out by controlled tests: concurrency, transcript size, session-specific state,

CLI version skew

Repro steps

  1. Desktop app ≥ 1.32352.1, any idle app-managed session
  2. From another session: session-management send_message (or SendMessage) to it
  3. Observe: message appears in target transcript; target shows busy; no output ever;

~16 min later the "stopped responding" error; on resume the message is gone from
context

Related: #86014 (cross-session SendMessage reports success, messages not delivered /
sessions stuck) — this report adds a debug-log capture of the turn-start dying in the
count_tokens fan-out and the hooks-not-loading observation on the same entrypoint.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗