[Bug] Feishu direct chats can miss the parent reply after sessions_spawn subagent completion even though the assistant reply exists in session history

Summary

In a Feishu direct chat, a parent session can successfully spawn a subagent with sessions_spawn, receive the subagent completion event, generate the final assistant reply, and still fail to show that reply to the human user.

From the parent session's point of view, the reply was generated. From the user's point of view, nothing arrived.

This looks like a delivery / visibility gap between:

1. subagent completion announce / parent re-entry
2. the parent assistant final answer
3. Feishu outbound delivery for that final answer

Environment

• OpenClaw version: 2026.3.23-2
• Channel: Feishu direct chat
• Session kind: agent:main:feishu:direct:*
• Model observed during tests: gpt-5.4-mini and gpt-5.4
• Host: Linux / systemd gateway

What happened

We repeatedly ran this pattern:

1. user asks assistant to spawn a subagent
2. assistant calls sessions_spawn(..., mode:"run", runtime:"subagent")
3. assistant calls sessions_yield(...) to wait for the completion event
4. subagent finishes successfully
5. an inter-session completion event is injected into the parent session
6. the parent assistant produces a normal final answer based on that event
7. the human user sometimes does not see that answer in Feishu

Important evidence

A. The parent reply exists in session history

Using sessions_history on the Feishu direct session, I can see:

• the user-visible request
• the sessions_spawn / sessions_yield sequence
• the injected subagent completion event
• the assistant final answer immediately after that event

So this is not just "the model never replied".

B. Docs say delivery is best-effort

The docs explicitly say:

• delivery / announce happens after completion
• delivery is best-effort
• status: "ok" confirms the agent run completed, not that announce/delivery succeeded

Relevant docs:

• docs/zh-CN/tools/index.md lines ~451-453
• docs/zh-CN/concepts/session-tool.md lines ~173-177

C. Explicit Feishu card send succeeds

As a workaround, after one of these subagent completions we sent the result through the message tool using an explicit Feishu card send.

That explicit card was delivered successfully to the user.

This suggests the problem is more specific than "all Feishu outbound delivery is broken".

Additional oddity

Attempting explicit Feishu message.send with plain text (no card) did not work in this environment:

• first, tool validation complained that card was required
• then trying with an empty card returned HTTP 400
• sending a minimal Feishu card succeeded

This may be a separate bug / schema mismatch, but I mention it because it became the only reliable workaround for user-visible delivery during testing.

Expected behavior

When a subagent completion event is delivered back into the parent session, and the parent assistant generates a final answer in response, that answer should be delivered to the original Feishu conversation reliably.

At minimum, there should be a way to know whether:

• the parent assistant reply was generated
• the reply was handed off to the Feishu adapter
• the Feishu adapter accepted / delivered it

Actual behavior

• subagent run completes
• parent session receives completion event
• parent assistant final answer exists in transcript/history
• user sometimes reports seeing no reply in Feishu

Reproduction sketch

In Feishu DM:

1. Ask assistant to run a subagent arithmetic test.
2. Assistant does:
   • sessions_spawn({ runtime:"subagent", mode:"run", ... })
   • sessions_yield({ message:"[executing] ..." })
3. Wait for subagent completion event.
4. Let the parent assistant produce a normal final answer.
5. Observe that the final answer may exist in session history while not being visible in Feishu.

Suspected scope

Likely one of these:

1. parent re-entry reply after inter-session completion event is not always routed back through the original Feishu reply path
2. Feishu adapter does not reliably emit user-visible output for parent answers generated from inter-session completion events
3. transcript/session state marks the turn complete even when outbound delivery did not happen
4. there is no delivery acknowledgment path, so internal success is mistaken for user-visible success

Why this matters

This makes subagent workflows feel flaky in chat:

• internally, everything may be correct
• externally, the user experiences silence

That breaks trust in multi-agent orchestration, especially on messaging channels where the user only sees the outbound result.

Workaround used

Use an explicit message.send Feishu card after the subagent completion arrives, instead of relying only on the normal parent final-answer path.

That workaround succeeded in the same session where normal visible reply delivery was suspect.

Request

Could maintainers clarify whether this is:

• an expected limitation of the current announce/delivery path
• a Feishu adapter bug
• a parent re-entry / inter-session completion routing bug

And if it is a known issue, is there already a preferred workaround besides explicit outbound send?