Greptile Summary

This PR fixes a cross-routing bug (#34647) in the chat.send gateway path. Previously, chat.send parsed the session key and delivery context to decide whether to inherit an external channel's routing metadata (OriginatingChannel, OriginatingTo, AccountId, MessageThreadId). When the session had a stored Slack/Telegram/Feishu delivery context, the reply dispatcher would route responses to that external channel instead of back to the webchat connection.

The fix: Remove the 37-line session-key-parsing and route-inheritance block entirely. OriginatingChannel is now unconditionally set to INTERNAL_MESSAGE_CHANNEL ("webchat"), and OriginatingTo, AccountId, and MessageThreadId are always undefined for the chat.send code path.

Key observations:

• The two now-unused imports (parseAgentSessionKey, normalizeMessageChannel) are correctly cleaned up.
• The removed CHANNEL_AGNOSTIC_SESSION_SCOPES and CHANNEL_SCOPED_SESSION_SHAPES constants had no other usages in the file.
• Five tests are updated from asserting external-channel inheritance to asserting OriginatingChannel: "webchat", which correctly documents the new invariant.
• Acknowledged breaking change: API/CLI clients that previously relied on chat.send silently inheriting an external channel route (e.g., to forward a message to Slack via webchat) will lose that behaviour. The PR description explicitly calls this out and recommends using the explicit message tool instead. This is a reasonable trade-off given that the previous behaviour was a routing bug from the user's perspective.

Confidence Score: 4/5

• Safe to merge — the fix is narrow, well-tested, and correctly removes a cross-routing bug; the one acknowledged risk (API/CLI route-inheritance breakage) is a reasonable and documented trade-off.
• The change is minimal (remove complex conditional routing, replace with four constant assignments), imports are cleaned up correctly, and 13 tests all pass with the updated expectations. The only non-trivial risk — that programmatic callers relying on implicit external-channel routing via chat.send will silently lose that routing — is explicitly documented in the PR description, reducing the likelihood of an unpleasant surprise post-merge.
• No files require special attention. Both changed files are clean.

_{Last reviewed commit: c2e4e0f}

Quick status pass on the routing cluster: this is still the canonical shared-main fix path, but I’m not merging it yet because the Bun test job is red while the other required checks are green.

Once that failing job is rerun or fixed, this remains the right PR to land for the shared-main Control UI cross-routing issue tracked in #33619.

The red Bun job here is not showing a repository failure. It failed while downloading Bun 1.3.9+cf6cdbbba with a 404 from the upstream release URL.

I’ve rerun the failed jobs so we can separate CI infrastructure noise from an actual code problem before deciding merge readiness.

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟠 Denial of Service via unbounded sessionKey.split(":") in chat.send routing resolution

Description

The resolveChatSendOriginatingRoute helper performs unbounded split(":") operations on the client-supplied sessionKey (or its parsed rest). Because sessionKey has no maxLength constraint in the gateway RPC schema, an attacker can send a very large string containing many : delimiters, causing String.prototype.split to allocate a huge array and consume excessive CPU/memory.

Impact:

• A single crafted chat.send request can trigger large allocations and high CPU usage in the gateway process.
• This can lead to process slowdown or crash (DoS), especially with payloads near the WebSocket maxPayload limit.

Vulnerable code:

const sessionScopeParts = (parsedSessionKey?.rest ?? params.sessionKey)
  .split(":")
  .filter(Boolean);

Example payloads (illustrative):

• sessionKey = ":".repeat(10_000_000) (creates an array with ~10M+ elements before filtering)
• sessionKey = "agent:main:" + ":".repeat(10_000_000)

Even though the gateway has a maxPayload limit (25MB), a 25MB string containing mostly : characters can still create an enormous split array and exhaust memory.

Recommendation

Add strict bounds and avoid unbounded split on attacker-controlled strings.

Recommended defenses (layered):

1. Enforce a maximum sessionKey length at the protocol/schema level (and ideally also at runtime):

​// Example: restrict to a reasonable size
export const ChatSendParamsSchema = Type.Object({
  sessionKey: Type.String({ minLength: 1, maxLength: 256 }),
  ​// ...
});

2. Parse only the small number of tokens you actually need, using the limit argument to split:

const rawScope = parsedSessionKey?.rest ?? params.sessionKey;
​// only need first 3 tokens (head + 2 shape candidates)
const sessionScopeParts = rawScope.split(":", 4).filter((p) => p.trim().length > 0);

3. Consider rejecting keys with excessive delimiter counts or total length early:

if (rawScope.length > 256) {
  return { originatingChannel: INTERNAL_MESSAGE_CHANNEL, explicitDeliverRoute: false };
}

These changes prevent pathological sessionKey inputs from causing large intermediate allocations.

Analyzed PR: #34669 at commit 15ecd73

_{Last updated on: 2026-03-06T14:24:29Z}

Reposting this fix on a maintainer branch as #38418.

The underlying shared-main chat.send stale-route issue is still separate from the fixes that merged in #36030 and #37135, so the narrowed/rebased change continues there.