1. src/auto-reply/reply/dispatch-from-config.ts, line 571-580 (link)

   Stale comment and log message under new visibleReplyMode path

   The plugin-binding skip block's comment and log message both say "Under deny" / "sendPolicy: deny", but suppressDelivery now also fires when toolOnlyVisibleReplies is true. A Discord channel in visibleReplyMode: "auto" that happens to own a plugin binding will have its plugin handler silently skipped with a misleading log line — the comment rationale ("emit outbound replies we cannot rewind") may not apply to all plugin handlers, and the stale message makes debugging harder.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/auto-reply/reply/dispatch-from-config.ts
   Line: 571-580
   
   Comment:
   **Stale comment and log message under new `visibleReplyMode` path**
   
   The plugin-binding skip block's comment and log message both say "Under deny" / "sendPolicy: deny", but `suppressDelivery` now also fires when `toolOnlyVisibleReplies` is true. A Discord channel in `visibleReplyMode: "auto"` that happens to own a plugin binding will have its plugin handler silently skipped with a misleading log line — the comment rationale ("emit outbound replies we cannot rewind") may not apply to all plugin handlers, and the stale message makes debugging harder.
   
   How can I resolve this? If you propose a fix, please make it concise.

2. src/agents/system-prompt.ts, line 382 (link)

   target instruction unchanged despite new optional-target fallback in auto mode

   In visibleReplyMode: "auto", handle-action.ts now falls back to readCurrentDiscordTarget when to/target are absent, so agents don't need to know the channel ID. However, this line still unconditionally tells all agents "For action=send, include target and message." An agent in auto mode trying to compose a reply may unnecessarily attempt to look up a channel ID. Wrapping this line in the same visibleReplyMode branch or explicitly noting that target defaults to the current channel would prevent the instruction from conflicting with the intended usage.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/agents/system-prompt.ts
   Line: 382
   
   Comment:
   **`target` instruction unchanged despite new optional-target fallback in auto mode**
   
   In `visibleReplyMode: "auto"`, `handle-action.ts` now falls back to `readCurrentDiscordTarget` when `to`/`target` are absent, so agents don't need to know the channel ID. However, this line still unconditionally tells all agents "For `action=send`, include `target` and `message`." An agent in auto mode trying to compose a reply may unnecessarily attempt to look up a channel ID. Wrapping this line in the same `visibleReplyMode` branch or explicitly noting that `target` defaults to the current channel would prevent the instruction from conflicting with the intended usage.
   
   How can I resolve this? If you propose a fix, please make it concise.

Description

message(action=send) can be coerced (e.g., via prompt injection in a group/channel) to send content to other conversations within the same provider (e.g., other Discord channels), because cross-context enforcement allows same-provider sends by default.

• The new message-tool-only prompting explicitly encourages delivering visible output via message(action=send) and makes target optional by defaulting to the current channel.
• However, if an attacker convinces the model to include an explicit target/to (e.g., channel:<other-id>), the server-side policy check returns early when allowWithinProvider is not set to false (default per schema: true).
• This enables cross-channel data exfiltration within the same provider, potentially leaking private/model-internal content or sensitive session context to an attacker-controlled channel.

Vulnerable logic:

​// default: allowWithinProvider === true
if (allowWithinProvider) {
  return;
}

This is especially risky in group contexts where untrusted users can influence the assistant and where the new message-tool-only mode makes tool sends the primary way to produce visible output.

Recommendation

Harden cross-context messaging defaults and require explicit opt-in.

Suggested changes:

1. Default-deny same-provider cross-context sends unless explicitly enabled:

const allowWithinProvider =
  params.cfg.tools?.message?.crossContext?.allowWithinProvider === true;
if (!allowWithinProvider) {
  ​// enforce same-target unless explicitly allowed
}

2. In message-tool-only delivery mode, consider forcing same-target regardless of config unless the run is explicitly marked as trusted/owner-initiated.

3. Add an allowlist mechanism (e.g., permitted target IDs per session/channel) or require a higher-trust capability for cross-context sends.

4. Log and/or alert on cross-context sends (target differs from toolContext.currentChannelId) to detect abuse.

Description

sendPolicy: "deny" is resolved in dispatchReplyFromConfig, but the refactor changes the semantics of suppression to only cover automatic reply/notice/indicator delivery while explicitly stating that "explicit message tool sends remain available".

This creates a policy bypass if sendPolicy: deny is intended to mean no outbound side effects:

• Input: session/config sendPolicy is resolved to deny.
• Enforcement: dispatchReplyFromConfig sets suppressDelivery to suppress automatic replies, but does not disable outbound-capable tools.
• Sink: the message tool (src/agents/tools/message-tool.ts) can still execute runMessageActionForTool(...) which can send messages/reactions/broadcasts, producing outbound side effects despite sendPolicy: deny.

Vulnerable logic (policy narrowed to automatic delivery only):

​// blocked; explicit message tool sends remain available.
const sendPolicyDenied = sendPolicy === "deny";
...
const suppressDelivery = sendPolicyDenied || suppressAutomaticSourceDelivery;

Because message-tool.ts contains no sendPolicy checks, an agent operating in a denied session can still call message(action=send|reply|broadcast|react|...) to deliver outbound content.

Recommendation

Treat sendPolicy: "deny" as a hard guard for all outbound side effects, including tool-driven sends.

Options:

1. Disable outbound-capable tools when sendPolicyDenied is true (preferred):

• Pass a flag into the embedded/CLI runner to disable the message tool (and any other outbound tools like sessions_send).

2. Enforce in the tool implementation (defense-in-depth):

• Add a sendPolicy/deliveryAllowed boolean into tool options and reject outbound actions when denied.

Example (tool-level guard):

​// inside message tool handler
if (options?.sendPolicy === "deny" && action !== "read") {
  throw new Error("Outbound messaging is blocked by sendPolicy: deny");
}

Ensure the enforcement covers all outbound actions (send, reply, broadcast, reactions, uploads, etc.), not just final/automatic reply dispatch.

Description

In Discord guild/group privacy mode (sourceReplyDeliveryMode: "message_tool_only"), the handler suppresses ack/status reactions and draft streaming, but still starts Discord typing indicators.

• Input: cfg.messages.groupChat.visibleReplies controls sourceReplyDeliveryMode for guild messages
• When it resolves to "message_tool_only", the code disables reactions and draft streaming
• However, createChannelReplyPipeline() is always configured with typing.start: sendTyping(...), which will produce a Discord-visible typing indicator in the channel/thread even when replies are intended to be tool-only/private

This leaks that the bot is actively processing a message, which can undermine the intended “no visible output unless message tool is used” privacy guarantee.

Vulnerable code (typing is unconditional):

const { onModelSelected, ...replyPipeline } = createChannelReplyPipeline({
  ...
  typing: {
    start: () => sendTyping({ rest: feedbackRest, channelId: typingChannelId }),
    ...
  },
});

Recommendation

Gate typing indicators behind sourceReplyDeliveryMode !== "message_tool_only" (similar to reactions/streaming), or add a dedicated config flag for typing in tool-only mode.

Example:

const typingEnabled = sourceReplyDeliveryMode !== "message_tool_only";

const { onModelSelected, ...replyPipeline } = createChannelReplyPipeline({
  cfg,
  agentId: route.agentId,
  channel: "discord",
  accountId: route.accountId,
  typing: typingEnabled
    ? {
        start: () => sendTyping({ rest: feedbackRest, channelId: typingChannelId }),
        onStartError: (err) => { /* ... */ },
        maxDurationMs: DISCORD_TYPING_MAX_DURATION_MS,
      }
    : undefined,
});

This prevents any Discord-visible activity in tool-only mode unless explicitly requested via a tool action.