Context
Follow-up from PR #392.
The Nyx relay path should deliver the current inbound Lark reply through the channel runtime using the relay reply token. PR #392 tightened the NyxID chat prompt so the model does not call lark_messages_reply, lark_messages_react, or nyxid_proxy_execute to deliver the current relay answer.
Problem
The prompt fix is necessary, but the Lark tool layer still has no defense-in-depth. If a future prompt regression, cached model behavior, or alternate system prompt calls lark_messages_reply / lark_messages_react during an inbound relay turn, those tools can still route through /proxy/s/api-lark-bot/... and hit the wrong Lark app identity.
Proposal
Add a runtime guard in LarkMessagesReplyTool and LarkMessagesReactTool for current inbound relay turns. When channel context indicates the current message is a relay turn, return a clear structured tool error telling the model/runtime to use the channel relay reply path instead of the Lark proxy path.
Potential signals to evaluate:
- channel runtime metadata such as
channel.platform_message_id
- any existing relay/reply-token context exposed to tools
- whether the operation targets the current inbound message versus an explicitly user-requested external Lark message
Notes
This is not blocking PR #392 because the prompt now prevents the observed failure path, but it would make the boundary more robust.
Context
Follow-up from PR #392.
The Nyx relay path should deliver the current inbound Lark reply through the channel runtime using the relay reply token. PR #392 tightened the NyxID chat prompt so the model does not call
lark_messages_reply,lark_messages_react, ornyxid_proxy_executeto deliver the current relay answer.Problem
The prompt fix is necessary, but the Lark tool layer still has no defense-in-depth. If a future prompt regression, cached model behavior, or alternate system prompt calls
lark_messages_reply/lark_messages_reactduring an inbound relay turn, those tools can still route through/proxy/s/api-lark-bot/...and hit the wrong Lark app identity.Proposal
Add a runtime guard in
LarkMessagesReplyToolandLarkMessagesReactToolfor current inbound relay turns. When channel context indicates the current message is a relay turn, return a clear structured tool error telling the model/runtime to use the channel relay reply path instead of the Lark proxy path.Potential signals to evaluate:
channel.platform_message_idNotes
This is not blocking PR #392 because the prompt now prevents the observed failure path, but it would make the boundary more robust.