Greptile Summary

This PR attempts to fix Telegram announce target resolution by bypassing the normalizeTarget call for the "telegram" channel and returning the raw chat ID instead of a prefixed form like "group:-1001720118846". The fix and accompanying tests are well-scoped — but there is a critical off-by-one in the implementation: the Telegram branch returns kindTarget rather than id, and kindTarget is still built as "group:<id>" (line 61). Both new tests expect to: "-1001720118846" and will fail against the current code.

• The fix in resolveAnnounceTargetFromKey should use id (the bare numeric string) rather than kindTarget in the normalizedChannel === "telegram" branch — kindTarget still carries the group: prefix that the Telegram send-path rejects.
• The two new test cases correctly specify the desired behavior (raw numeric to for plain group and topic session keys); they serve as a good regression harness once the one-word change (kindTarget → id) is applied.

Confidence Score: 1/5

• Not safe to merge — the core fix uses kindTarget instead of id, so the group: prefix is not removed and the bug persists; both new tests will fail.
• The Telegram bypass branch returns kindTarget ("group:-1001720118846") rather than id ("-1001720118846"). This means to is still a prefixed string, exactly what the Telegram send-path rejects. The fix is one word away from being correct (id instead of kindTarget), but in its current state the code does not solve the reported problem and the tests it introduces will fail.
• src/agents/tools/sessions-send-helpers.ts — lines 63-68, the normalized assignment for Telegram

This is a comment left during a code review.
Path: src/agents/tools/sessions-send-helpers.ts
Line: 63-68

Comment:
**Fix still includes `group:` prefix for Telegram targets**

The fix assigns `normalized = kindTarget` for Telegram, but `kindTarget` for a group session key is `"group:<id>"` (computed at line 61: `return kind === "channel" ? \`channel:${id}\` : \`group:${id}\``). So `to` ends up as `"group:-1001720118846"` — the same prefixed form that caused the original validation failure — not the raw numeric `"-1001720118846"` expected by both new tests.

Tracing through `"agent:main:telegram:group:-1001720118846"`:
- `kind = "group"`, `id = "-1001720118846"`
- `kindTarget = "group:-1001720118846"` (line 61)
- `normalized = kindTarget = "group:-1001720118846"` (new branch)
- `to = "group:-1001720118846"` — test expects `"-1001720118846"` → **test fails**

The fix should use `id` (the bare numeric value) instead of `kindTarget`:

```suggestion
  const normalized =
    normalizedChannel === "telegram"
      ? id
      : normalizedChannel
        ? getChannelPlugin(normalizedChannel)?.messaging?.normalizeTarget?.(kindTarget)
        : undefined;
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: bc02ee8}

Addressed the review feedback in a follow-up commit.

• switched the Telegram branch in resolveAnnounceTargetFromKey(...) from kindTarget to the bare id
• kept threadId / topic extraction unchanged
• reran the narrow regression test:
  • corepack pnpm exec vitest run src/agents/tools/sessions-send-helpers.test.ts ✅ (2/2)

This should close the group:<id> vs numeric chat ID issue called out in review.

Refreshed this PR on top of the latest main to keep the diff current and drop stale merge-base noise. No semantic change intended beyond rebasing the fix onto current upstream.

Closing this as implemented after Codex review.

Current main already resolves Telegram announce targets to bare numeric chat IDs, preserves topic/thread IDs separately, and ships a regression test for the exact session-key shape in this PR. The same implementation is already present in release v2026.4.23, so there is no remaining delta for this PR to land.

What I checked:

• Current helper implementation: On current main, resolveAnnounceTargetFromKey(...) parses the session key, delegates session-aware target shaping to the channel plugin, and returns threadId separately. This is the announce path relevant to the PR. (src/agents/tools/sessions-send-helpers.ts:26, 5fe333ada85a)
• Current Telegram regression test: Current tests already assert that agent:main:telegram:group:-100123:topic:99 resolves to to: "-100123" with threadId: "99", matching the behavior this PR wants. (src/agents/tools/sessions-send-helpers.test.ts:24, 5fe333ada85a)
• Telegram session-key parsing: The bundled Telegram channel plugin resolves session conversation ids into chatId plus optional topicId, so announce routing keeps the numeric chat id and carries the topic separately. (extensions/telegram/src/session-conversation.ts:3, 5fe333ada85a)
• Telegram target normalization and send contract: Telegram target parsing strips the legacy telegram:group: internal form to the bare numeric id, and the send path still rejects non-numeric recipients. That means the current code already covers the bug described in this PR. (extensions/telegram/src/targets.ts:10, 5fe333ada85a)
• Numeric recipient requirement remains enforced: The Telegram send path still throws Telegram recipient must be a numeric chat ID when a recipient cannot be normalized to a numeric id, which is the exact failure mode described in the PR body. (extensions/telegram/src/send.ts:301, 5fe333ada85a)
• Already shipped in latest release: The same announce-helper/test and Telegram session-target files are already present in release tag v2026.4.23; diffing that tag against current main for these files produced no changes. (a9797214338b)

So I’m closing this as already implemented rather than keeping a duplicate issue open.

Review notes: reviewed against 5fe333ada85a; fix evidence: release v2026.4.23, commit a9797214338b.