When the message tool sent to a different chat (e.g., a group), the
agent's final response to the originating chat was incorrectly skipped
because HasSentInRound() was a simple bool that didn't distinguish
targets. Replace with HasSentTo(channel, chatID) that tracks all
send targets per round and only suppresses when the target matches.
Fixes cross-conversation message causing "Processing..." to hang.
- Add `reaction` tool that reacts to a message (defaults to current inbound message via context)
- Extend `message` tool with optional `reply_to_message_id` parameter
- Introduce `WithToolInboundContext` to inject inbound message IDs into tool execution context
- Surface `MessageID` and `ReplyToMessageID` in `processOptions` for tool-surface consumption
Refs #2137
When the message tool sent to a different chat (e.g., a group), the
agent's final response to the originating chat was incorrectly skipped
because HasSentInRound() was a simple bool that didn't distinguish
targets. Replace with HasSentTo(channel, chatID) that tracks all
send targets per round and only suppresses when the target matches.
Fixes cross-conversation message causing "Processing..." to hang.
* fix: eliminate data races on shared tool instances
Signed-off-by: Boris Bliznioukov <blib@mail.com>
* fix: remove unused indirect dependency on github.com/gdamore/tcell/v2
Signed-off-by: Boris Bliznioukov <blib@mail.com>
* fix: reviewer comments improve context handling for tool execution and ensure defaults for non-conversation callers
Signed-off-by: Boris Bliznioukov <blib@mail.com>
---------
Signed-off-by: Boris Bliznioukov <blib@mail.com>
When the LLM returns multiple tool calls, they are now executed
concurrently using goroutines + sync.WaitGroup instead of sequentially.
Results are collected in an indexed slice and processed in original order
to preserve message ordering. MessageTool.sentInRound is changed to
atomic.Bool for thread safety.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Merge upstream/main into bugfix/fix-duplicate-telegram-messages.
Conflict resolutions:
- pkg/agent/loop.go: Adopt upstream's processSystemMessage which removes
runAgentLoop call entirely (subagents now communicate via message tool
directly). Keep PR's HasSentInRound() check in Run() for normal
message processing path.
- pkg/tools/message.go: Merge both changes - keep sentInRound tracking
from PR and adopt upstream's *ToolResult return type with Silent: true.
Two issues caused duplicate messages to be sent to users:
1. System messages (from subagent): processSystemMessage set SendResponse:true,
causing runAgentLoop to publish outbound. Then Run() also published outbound
using the returned response string, resulting in two identical messages.
Fix: processSystemMessage now returns empty string since runAgentLoop already
handles the send.
2. Message tool double-send: When LLM called the "message" tool during
processing, it published outbound immediately. Then Run() published the
final response again. Fix: Track whether MessageTool sent a message in the
current round (sentInRound flag, reset on each SetContext call). Run()
checks HasSentInRound() before publishing to avoid duplicates.
- Update all Tool implementations to return *ToolResult instead of (string, error)
- ShellTool: returns UserResult for command output, ErrorResult for failures
- SpawnTool: returns NewToolResult on success, ErrorResult on failure
- WebTool: returns ToolResult with ForUser=content, ForLLM=summary
- EditTool: returns SilentResult for silent edits, ErrorResult on failure
- FilesystemTool: returns SilentResult/NewToolResult for operations, ErrorResult on failure
- Temporarily disable cronTool in main.go (will be re-enabled in US-016)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Cytown