Error messages in sendMessageWhatsApp, sendReactionWhatsApp, and
sendPollWhatsApp included hardcoded \"WhatsApp\" references. This caused
confusion when cron jobs using other providers (e.g., Telegram) failed
with errors mentioning WhatsApp.
Changes error messages to be provider-agnostic while maintaining the
same error handling behavior.
Fixes#461Fixes#470
Co-Authored-By: Claude <noreply@anthropic.com>
- Add SignalReactionMessage type with emoji, targetAuthor, timestamp
- Handle reaction messages in monitor (log and skip for now)
- Prevents reactions from showing as unknown media
- Update MessageToolOptions type to include Slack threading options
- Remove duplicate threadTs property in slack/actions.ts
- Fix replyThreadTs parameter name in monitor.ts
- Update test to correctly verify 'first' mode threading behavior:
- 'off' mode: no threading unless already in a thread
- 'first' mode: first reply starts a thread
- Add new test case for 'first' mode threading
- Add shared hasRepliedRef state between auto-reply and tool paths
- Extract buildSlackThreadingContext helper in agent-runner.ts
- Extract resolveThreadTsFromContext helper in slack-actions.ts
- Update docs with clear replyToMode table (off/first/all)
- Add tests for first mode behavior across multiple messages
Add 30-second timeout after WebSocket opens to detect when Discord
never sends HELLO (zombie state). If isConnected stays false after
timeout, forces a fresh connection instead of hanging indefinitely.
Relates to #595
Add listener for Carbon GatewayPlugin 'debug' events to capture WebSocket
connection state changes. Critical events (close, reconnect, resume) are
logged at INFO level always; all debug messages logged in verbose mode.
Fixes#595
Enables multiple agents to process the same message simultaneously,
allowing teams of specialized agents with atomic tasks to work together
in the same group using one phone number.
Key features:
- Configure multiple agents per WhatsApp group/DM via routing.broadcast
- Parallel (default) or sequential processing strategies
- Full session isolation (separate history, workspace, tools per agent)
- Minimal code changes (~50 lines in auto-reply.ts)
- Backward compatible with existing routing
Use cases:
- Specialized agent teams (code reviewer + security scanner + docs)
- Multi-language support (EN + DE + ES agents)
- Quality assurance workflows (support + QA agents)
- Task automation (tracker + logger + reporter)
Example config:
{
"routing": {
"broadcast": {
"strategy": "parallel",
"120363403215116621@g.us": ["alfred", "baerbel", "assistant3"]
}
}
}
This enables scaling to hundreds of focused micro-agents on a single
phone number, each handling specific atomic tasks.
## Problem
When messages arrived while the agent was busy processing a previous message,
the same message could be enqueued multiple times into the followup queue.
This happened because Discord's event system can emit the same message multiple
times (e.g., during reconnects or due to slow listener processing), and the
followup queue had no deduplication logic.
This caused the bot to respond to the same user message 2-4+ times.
## Solution
Add simple exact-match deduplication in `enqueueFollowupRun()`: if a prompt
is already in the queue, skip adding it again. Extracted into a small
`isPromptAlreadyQueued()` helper for clarity.
## Testing
- Added test cases for deduplication (same prompt rejected, different accepted)
- Manually verified on Discord: single response per message even when multiple
events fire during slow agent processing
Recent changes added recordProviderActivity calls with accountId, but
the type definition and usage didn't include accountId in ActiveWebSendOptions.
This fix adds the optional accountId field and uses optional chaining
when accessing it to handle cases where options is undefined.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Replaces Type.Integer with Type.Number and simplifies the sessions_send tool schema to avoid anyOf/oneOf unions that cause 400 errors with Google Cloud Code Assist API.
Add --auth-choice minimax-api for direct MiniMax API usage at
https://api.minimax.io/anthropic using the anthropic-messages API.
Changes:
- Add applyMinimaxApiConfig() function with provider/model config
- Add minimax-api to AuthChoice type and CLI options
- Add handler and non-interactive support
- Fix duplicate minimax entry in envMap
- Update live test to use anthropic-messages API
- Add 11 unit tests covering all edge cases
- Document configuration in gateway docs
Test results:
- 11/11 unit tests pass
- 1/1 live API test passes (verified with real API key)
Co-Authored-By: Claude <noreply@anthropic.com>
