sessions_send delivery.status stays "pending" even after message is delivered
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
pendingFinalDeliveryretry 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
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗