Claude agent: user message silently dropped when session resumes from an interrupted turn — no reply is sent

[KyleCaiZJU]

Summary

When a user sends a message while/right after the previous run left the session in an interrupted state (e.g. the previous claude -p --resume process exited while a Task subagent was still in flight), the new run produces zero assistant output, and the bridge treats it as a normal run — so no reply is sent at all. The user sees nothing until they send another message.

Environment

• lark-channel-bridge 0.6.0 (claude agent, --output-format stream-json, COT enabled, messageReply: markdown)
• claude 2.1.224 (headless claude -p --resume <session>)

Repro sequence

1. User asks a long task (e.g. deep research). The claude process spawns a Task subagent and waits on it.
2. The run's stream ends / the process exits while the subagent is still running (subagent completion notification arrives after the parent process exited: "No completion record was found… It may have been running when the previous Claude Code process exited").
3. User sends a follow-up message. Bridge starts a new claude -p --resume <session> run on the same session.
4. The resumed process finds the last turn incomplete, writes [Request interrupted by user] into the transcript, and exits in ~2.7s without calling the model (no assistant turn follows; on the next message the harness additionally emits a synthetic <synthetic> "No response requested." turn).
5. Bridge: run completes "normal" with zero events → sendFinalReply hits skip-empty → nothing sent. Log shows [run.post-done-exit-timeout] (process didn't exit after stream end) and the run duration is ~2.7s.

Observed logs

▸ p2p/... msg=eaf165: 总结一下给我…
  ▶ run start scope=... run=ad30ac queue=0ms
  ◇ cot created message=64d428 cot=609674
  ✓ run normal scope=... run=ad30ac duration=2.7s
  ✓ ... done
  ◇ cot completed cot=609674 reason=done
▸ p2p/... msg=7bce9f: 没有任何消息      ← user notices no reply

(no sent markdown line for run ad30ac; the user's second message triggers a real resume which answers normally)

Transcript around the failure (claude headless, session jsonl):

06:28:43 USER  <bridge_context> 总结一下给我…
06:28:45 USER  [Request interrupted by user]     ← written by the resumed process
(no assistant turn at all until the NEXT user message at 06:32:50)
06:32:50 USER  Continue from where you left off.
06:32:50 ASSISTANT <synthetic>  No response requested.

Expected behavior

A run triggered by a user IM message that produces zero assistant text should not silently succeed:

• either the bridge should detect "zero output on a user message" and retry / send a fallback notice, or
• the resume flow should not swallow the incoming prompt when the previous turn was interrupted.

Cron/scheduled broadcasts apparently don't go through this reply path today, so a fallback on empty output looks safe, but the bridge may want to distinguish message source.

Notes

• 0.7.0's "fix: no content" (13cda8d) only prevents the eager progress-stream placeholder for content-less runs; it does not fix the dropped-reply case (that fix intentionally sends nothing for a content-less run, which is exactly the silent behavior reported here).