sessions_send delivery.status stays "pending" even after message is delivered

Resolved 💬 1 comment Opened Jun 23, 2026 by RichChen01 Closed Jun 23, 2026

Bug Description

There is a state tracking inconsistency in the sessions_send tool: delivery.status remains "pending" even after the inter-session message has been successfully delivered and confirmed by the target session.

Evidence Chain (from transcript)

Line 1080: agent calls sessions_send (send "drink water" reminder)
Line 1081: returns delivery.status = "pending"
Line 1082: agent says "✅ 饮水提醒已发送到主会话!"
Line 1083: [Inter-session message] sourceSession=agent:main:main
           ← Main session actually received it and replied with confirmation!
Line 1084: agent processes receipt "饮水提醒已确认送达"

Root Cause

The message was actually delivered (proven by the inter-session message receipt and the main session's confirmation reply). However, delivery.status was never updated from "pending" to "delivered" when the inter-session message receipt arrived.

The delivery.status field only represents the initial state of "request accepted, delivery in progress", but it is not updated when the actual delivery confirmation comes back.

Symptoms

  • Reality: Message delivered successfully (confirmed by inter-session message receipt)
  • State tracking: Harness still sees delivery.status = "pending", thinks delivery failed
  • Consequence: At session end, the harness finds pending deliveries and triggers pendingFinalDelivery retry mechanism, causing unnecessary retries for messages that were already delivered

Expected Behavior

When the inter-session message receipt is received (confirming the target session got the message), delivery.status should be updated from "pending" to "delivered" so the harness does not trigger redundant retries.

Environment

  • Claude Code (version observed: latest as of June 2026)
  • sessions_send tool with inter-session message delivery

View original on GitHub ↗

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