fix(send_message): route bare in-turn target to current channel, not home

[Kyzcreig]

Problem

A send_message / react call with no explicit chat target silently fell back to the platform's global home channel. When an agent posted a mid-turn update from a non-home channel (e.g. a Discord project channel), the message leaked into the home channel — sometimes a different platform (Telegram DM) entirely.

Real incident (2026-06-21): a long agent turn in Discord #instacart called send_message with a bare target; the progress checkpoint surfaced in the Discord home channel #hermes instead. agent.log shows the exact two-step signature — send_message error "Both 'target' and 'message' are required" then send_message completed (200 chars) — and the leaked text landed in the home-channel session at the same millisecond.

Root cause

_handle_send (and the identical sibling _handle_react) default an unspecified chat_id to config.get_home_channel(platform). That is correct for cron/CLI/standalone, but inside a live messaging turn the destination should be the channel the turn is happening in. target is optional in the schema ("required": []) and the description literally said "'platform' (uses home channel)", so a bare target was a documented path straight to the leak.

Fix

A single tri-state resolver, _resolve_send_target(platform_name):

• ORIGIN — a real messaging origin is bound → route to the turn's own channel (read from the task-local HERMES_SESSION_* contextvars the gateway binds per turn).
• IN_TURN_UNRESOLVABLE — messaging origin bound but not resolvable for the requested platform → actionable error, never home.
• NOT_IN_TURN — no messaging origin (cron / CLI / TUI / desktop / ACP) → existing home behavior, unchanged.

The home-channel lookup is reachable only on the NOT_IN_TURN branch, so a live messaging turn can never silently hit home (structural, not emergent).

_has_messaging_origin() gates on an actually-bound messaging platform (approval._get_session_platform() truthiness, minus cron) — deliberately narrower than _is_gateway_approval_context(), because the TUI/desktop/ACP gateways set HERMES_GATEWAY_SESSION without binding a messaging platform; using the broad helper would turn their legitimate bare→home sends into errors.

Both _handle_send and _handle_react route through the shared resolver (whole bug class, not just the reported site). Schema descriptions (top-level + target property) updated to match; origin thread id is preserved; a logger.info records origin-routed sends.

Reproduction

# pre-fix: in a Discord turn on channel A with home=B
send_message(target="discord", message="x")   -> delivered to B (LEAK)
# post-fix
send_message(target="discord", message="x")   -> delivered to A

Tests

tests/tools/test_send_message_origin.py — 9 cases, real _handle_send/_handle_react path, only the network send + config stubbed:

• bare send in a live turn → origin channel (the regression guard for the leak)
• bare react in a live turn → origin channel (sibling path)
• no context (cron/CLI) → home (unchanged)
• HERMES_GATEWAY_SESSION set, no platform bound (TUI/desktop/ACP) → home, not an error
• cron (HERMES_CRON_SESSION) → home
• unresolvable in-turn origin → error, not home
• explicit cross-channel target unchanged
• resolver reads task-local session context
• origin thread id preserved

All 9 pass; ruff clean; no regression in the existing send_message suites.

Scope / non-goals

• Cron/CLI/TUI/desktop/ACP home-default delivery is preserved exactly.
• delegate_task subagent bare sends are out of scope: contextvars don't cross the executor boundary, so a subagent has no bound messaging origin → falls to home (today's behavior, never worse). The reported leak was a main-session send.

Spec: docs/specs/PRD-send-message-origin-leak.md (2 Opus review passes; Pass-2 caught and fixed the TUI/desktop over-broad-gate blocker).

[github-actions]

🔎 Lint report: fix/send-message-origin-leak vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 11252 on HEAD, 11244 on base (🆕 +8)

🆕 New issues (3):

Rule	Count
unresolved-attribute	2
unresolved-import	1

First entries

tests/tools/test_send_message_origin.py:29: [unresolved-import] unresolved-import: Cannot resolve imported module `pytest`
tests/tools/test_send_message_origin.py:291: [unresolved-attribute] unresolved-attribute: Attribute `kwargs` is not defined on `None` in union `_Call | None`
tests/tools/test_send_message_origin.py:290: [unresolved-attribute] unresolved-attribute: Attribute `args` is not defined on `None` in union `_Call | None`

✅ Fixed issues: none

Unchanged: 5874 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

[greptile-apps]

Greptile Summary

This PR fixes a silent home-channel leak where a bare-platform send_message or react call during a live messaging turn routed to the global home channel instead of the channel the turn was happening in. It introduces a shared tri-state resolver (_resolve_send_target) used by both _handle_send and _handle_react.

• ORIGIN (live messaging turn, same platform): routes to the turn's own chat_id/thread_id read from task-local ContextVars.
• IN_TURN_UNRESOLVABLE (live turn but different platform requested): returns an actionable error, never falls through to home.
• NOT_IN_TURN (cron, CLI, TUI, desktop, ACP): preserves existing home-channel behavior unchanged.
• Nine regression tests cover the primary fix and all boundary contexts.

Confidence Score: 4/5

The core fix is structurally sound; one typo in the secondary fallback branch silently drops thread IDs when that path fires.

The primary routing logic is correct and well-tested. However, the session-key fallback inside _interactive_origin (line 211) uses parsed.get(session_id) — a key that _parse_session_key never produces — instead of parsed.get(thread_id). When that fallback fires, the thread ID is silently dropped and the message lands at channel root rather than the correct thread.

tools/send_message_tool.py line 211: wrong dict key in the fallback branch of _interactive_origin.

Important Files Changed

Filename	Overview
tools/send_message_tool.py	Adds tri-state origin resolver; primary path correct, but session-key fallback branch has a wrong dict key (session_id vs thread_id) that silently drops thread IDs.
tests/tools/test_send_message_origin.py	9 regression tests covering the fix and boundary cases; fallback session-key parse path with thread ID is not exercised.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["send_message / react (no explicit chat_id)"] --> B["_resolve_send_target(platform)"]
    B --> C{"_has_messaging_origin()?"}
    C -- "False (cron/no platform)" --> D["NOT_IN_TURN"]
    C -- "True (platform bound)" --> E["_interactive_origin(platform)"]
    E --> F{"session platform == requested?"}
    F -- "Yes + chat_id set" --> G["ORIGIN: deliver to turn channel"]
    F -- "No / chat_id empty" --> H["Parse session_key"]
    H --> I{"key platform matches?"}
    I -- "Yes + chat_id in key" --> G
    I -- "No" --> J["return None"]
    J --> K["IN_TURN_UNRESOLVABLE: error"]
    D --> L["home channel from config"]
    L --> M["Deliver to home"]
    G --> N["Deliver to origin channel"]
    K --> O["Return error JSON"]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A["send_message / react (no explicit chat_id)"] --> B["_resolve_send_target(platform)"]
    B --> C{"_has_messaging_origin()?"}
    C -- "False (cron/no platform)" --> D["NOT_IN_TURN"]
    C -- "True (platform bound)" --> E["_interactive_origin(platform)"]
    E --> F{"session platform == requested?"}
    F -- "Yes + chat_id set" --> G["ORIGIN: deliver to turn channel"]
    F -- "No / chat_id empty" --> H["Parse session_key"]
    H --> I{"key platform matches?"}
    I -- "Yes + chat_id in key" --> G
    I -- "No" --> J["return None"]
    J --> K["IN_TURN_UNRESOLVABLE: error"]
    D --> L["home channel from config"]
    L --> M["Deliver to home"]
    G --> N["Deliver to origin channel"]
    K --> O["Return error JSON"]

Loading

_{Reviews (1): Last reviewed commit: "fix(send_message): route bare in-turn ta..." | Re-trigger Greptile}

[greptile-apps]

Wrong key name in the session-key fallback path — "session_id" does not exist in the dict returned by _parse_session_key. That function returns {"platform", "chat_type", "chat_id"} and optionally "thread_id" (only for dm/thread chat types). Using "session_id" always evaluates to None, so the fallback silently drops the thread ID every time it fires, causing messages to land at channel root instead of the correct thread.

Suggested change

	thread_id = (parsed.get("session_id") or "").strip() or None
	thread_id = (parsed.get("thread_id") or "").strip() or None

[greptile-apps]

AC7b covers the primary path, not the fallback

test_origin_preserves_thread_id sets both chat_id=ORIGIN_CHAT and thread_id=ORIGIN_THREAD via set_session_vars, so it always hits the primary branch of _interactive_origin (lines 196-200). The session_id / thread_id typo in the fallback branch (reached when the session vars have a platform but an empty chat_id, requiring resolution through _parse_session_key) is never exercised.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!