feat: add thread-reply action support for Feishu channel

[fatwang2]

Summary

• Add thread-reply to SUPPORTED_ACTIONS in src/messaging/outbound/actions.ts
• Implement case 'thread-reply' in handleAction switch, reusing existing readFeishuSendParams + deliverMessage with replyInThread=true

Problem

When using message(action="thread-reply") to reply within an existing Feishu topic/thread, the framework returns:

"Message action thread-reply not supported for channel feishu"

The OpenClaw core framework already supports the thread-reply action, but this extension's actions.ts did not declare or handle it.

Implementation

The fix reuses existing infrastructure — readFeishuSendParams extracts message parameters, then we override replyToMessageId (from messageId / message_id / replyTo params) and set replyInThread = true before passing to deliverMessage. This ensures the Feishu reply API is called with reply_in_thread: true, routing the message into the existing thread rather than creating a new topic.

Test plan

• Verified locally: message(action="thread-reply", messageId="...", message="...") successfully sends a reply into an existing Feishu thread
• Project builds successfully with npm run build

🤖 Generated with Claude Code

[HanShaoshuai-k]

Thanks for the PR! I have a few questions about the motivation and completeness before we merge.

Is there a concrete user scenario for this?

Currently, thread routing is handled automatically within the send action — when the agent is already inside a thread, readFeishuSendParams detects toolContext.currentThreadTs and sets replyInThread=true transparently. The LLM agent doesn't need to make any explicit choice.

The incremental value of a separate thread-reply action would be cross-context thread replies — i.e., replying into a thread the agent is not currently participating in. But the PR doesn't describe this scenario or link to a specific issue. Could you share the use case that motivated this?

Exposing it to the LLM without guidance may cause problems

Adding thread-reply to SUPPORTED_ACTIONS means it will be advertised to the LLM via describeMessageTool(). Without clear tool description guidance explaining when to use thread-reply vs send, the LLM may use it in situations where send already handles things correctly, introducing unnecessary ambiguity.

Suggestion

I'd prefer to hold off on this until we have:

1. A concrete use case that send cannot already cover
2. Proper tool description guidance so the LLM knows when to pick thread-reply over send

Happy to revisit once those pieces are in place. What do you think?

[fatwang2]

Thanks for the review!

Use case: SubAgent cross-context thread replies

When a user starts a long-running task inside a thread, I spawn a SubAgent to handle it asynchronously. Once the SubAgent completes, it needs to post the result back into the original thread. However, because the SubAgent runs in a separate context, it doesn't have toolContext.currentThreadTs — so send creates a new topic instead of replying in the original thread.

With thread-reply, the SubAgent can explicitly specify the messageId to reply into the correct thread regardless of its own context. This is a scenario that send cannot cover today.

Regarding tool description guidance

I looked into adding per-action descriptions, but the current framework doesn't seem to have a standard mechanism for this — other channels and actions don't include action-level descriptions either. Could you point me to where this kind of guidance should be added?

[HanShaoshuai-k]

Thanks for the context — the SubAgent cross-context reply scenario makes sense as a motivation.

That said, we don't have official SubAgent support in the framework yet, so we'd like to take some time to discuss internally how this capability should fit into the broader design before merging. We'll follow up here once we have a clearer direction.

Thanks for your patience!

[fatwang2]

After conducting extensive testing, I have found that even with these changes, we still cannot achieve our goal.

The task we completed in the chat via the subagent was supposed to allow for replying to notifications directly within the thread. However, it actually continues to automatically create a new topic for notifications instead of allowing a reply in the existing thread.

This is very confusing to me.

[HanShaoshuai-k]

@fatwang2 We've released the latest version (2026.3.26) which includes a fix for this thread session isolation issue. Could you please update the plugin to the latest version and give it a try?

[fatwang2]

It's still not working, even though I've already upgraded.

The following is the specific content of my test:

A request originated from an existing thread. Later, after a background task completed, the main session sent an asynchronous notification using message.send. The send target was the group chat, and the message referenced the original message via reply_to, but it was not explicitly bound to the original thread/topic.

From our logs, we can confirm only one explicit message.send call.
However, on the Feishu side, the result was two identical messages:
one appeared in the original thread one appeared in a newly created topic.

[HanShaoshuai-k]

It's still not working, even though I've already upgraded.

The following is the specific content of my test:

A request originated from an existing thread. Later, after a background task completed, the main session sent an asynchronous notification using message.send. The send target was the group chat, and the message referenced the original message via reply_to, but it was not explicitly bound to the original thread/topic.

From our logs, we can confirm only one explicit message.send call. However, on the Feishu side, the result was two identical messages: one appeared in the original thread one appeared in a newly created topic.

You mean two same message with same content? One in original thread and one in new thread?

[fatwang2]

yeah 😂

[HanShaoshuai-k]

yeah 😂

amazing, I will take a look.

[fatwang2]

I'm in your beta testing group on Feishu, so we can also communicate directly through Feishu.

[HanShaoshuai-k]

I'm in your beta testing group on Feishu, so we can also communicate directly through Feishu.

哪个群呀...

[fatwang2]

体验互助 5 群

[fatwang2]

Same issues

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}