Codex review: needs maintainer review before merge. Reviewed May 27, 2026, 7:39 PM ET / 23:39 UTC.

Summary
The branch updates Telegram send and draft fallback policy plus cron/heartbeat delivery context so forum-topic routes keep thread IDs while unsafe threadless retries fail closed, with focused regression tests.

PR surface: Source +216, Tests +97. Total +313 across 8 files.

Reproducibility: yes. Source inspection and the PR's base-fails/head-passes test proof identify the threadless-fallback boundary, and the live Telegram proof exercises invalid and valid forum-topic sends on the PR head.

Review metrics: 2 noteworthy metrics.

• Fallback policy change: 1 Telegram threadless fallback narrowed. Explicit non-General forum and direct topic sends now surface Telegram errors instead of retrying threadless, so maintainers should notice the upgrade behavior before merge.
• Session route persistence: 1 cron pre-run session write added. Explicit cron announce targets now persist delivery context that later automatic notices can reuse.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• none

Mantis proof suggestion
A native Telegram Desktop recording would materially help reviewers see that valid topic sends stay in-topic and invalid explicit topics do not post to General/root. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

telegram desktop proof: verify a valid non-General topic send lands in the requested topic and an invalid explicit topic does not post to General/root.

Risk before merge

• Existing operators who relied on stale explicit non-General forum or direct-topic sends falling back to a root chat will now see a Telegram error instead; this is intentional but compatibility-visible.
• The cron and heartbeat changes deliberately preserve stored topic routes for automatic notices, which can change where existing follow-up messages appear when sessions already carry topic metadata.
• Live proof covers the transport-sensitive Telegram send fallback path, while cron and heartbeat route reconstruction remain proven by focused tests rather than a full live scheduled cron/heartbeat run.

Maintainer options:

1. Accept fail-closed topic routing (recommended)
   Merge after a maintainer confirms stale explicit non-General and direct topic sends should error instead of retrying into the wrong chat surface.
2. Ask for full scheduled-flow proof
   Pause for a live cron or heartbeat run if maintainers want end-to-end proof that automatic notices keep the configured topic thread ID.
3. Redesign for legacy fallback
   If maintainers want root-chat fallback to remain available for existing setups, pause this PR and redesign the stricter behavior as an explicit opt-in mode.

Next step before merge
No narrow automated repair is identified; the remaining action is maintainer review of the compatibility, session-state, and message-delivery behavior before merge.

Security
Cleared: No supply-chain or security-boundary regression was found; the patch reduces cross-topic message leakage by failing closed on unsafe Telegram topic fallback.

Follow-up pushed in d40225f83e.

Addressed the prior review items:

• Added cfg: TELEGRAM_TEST_CFG to the new Telegram send/sticker/poll tests and removed stale previewTransport test options that no longer exist in the draft stream API.
• Added a CHANGELOG.md entry.
• Extended the fix beyond thread-not-found retry: explicit cron announce topic routes are now persisted into isolated-session delivery context, and heartbeat target reconstruction preserves stored topic thread IDs for plugin-owned group routes when the session only has deliveryContext or origin.chatType.

Verification run locally:

• pnpm test src/infra/outbound/targets.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts
• pnpm test src/infra/heartbeat-runner.ghost-reminder.test.ts src/cron/isolated-agent/session.test.ts src/cron/isolated-agent.delivery-awareness.test.ts src/cron/isolated-agent/delivery-target.test.ts
• pnpm test extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts
• pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts src/cron/isolated-agent.test-setup.ts src/cron/isolated-agent/run.ts src/infra/outbound/targets.test.ts src/infra/outbound/targets.ts
• git diff --check
• pnpm check:changed

Rebased and refreshed this PR on current main.

Current head: 54b7b0d1f842
Base tested: origin/main 3f590b48280e
OpenClaw package version tested: 2026.5.12-beta.1
Node/pnpm: v22.21.1 / 11.1.0

Updates in this refresh:

• Resolved the rebase conflicts against current main.
• Kept the original fail-closed behavior for explicit non-General Telegram forum topics.
• Preserved the cron/heartbeat topic-route work from d40225f83e.
• Ran a simplification pass and collapsed the threadless fallback policy into the shared Telegram helper, while keeping normal send and draft-preview DM behavior distinct.
• Updated the PR body with tested versions, base/head SHAs, and the remaining live-proof residual.

Local verification:

• pnpm test extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts
• pnpm test src/infra/outbound/targets.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts
• pnpm test src/infra/heartbeat-runner.ghost-reminder.test.ts src/cron/isolated-agent/session.test.ts src/cron/isolated-agent.delivery-awareness.test.ts src/cron/isolated-agent/delivery-target.test.ts
• pnpm check:changed
• git diff --check
• codex review --base origin/main

GitHub check status after push: mergeable, 88 checks passing, 20 skipped, 0 pending. The only failed check is still Real behavior proof, which is expected from the existing label/gate because I cannot provide after-fix live Telegram forum proof from this checkout. This needs maintainer override or a live Telegram bot/forum verification run.

Test-based reproduction proof

This is automated reproduction evidence for the threadless-fallback boundary in this PR. It is not a live Telegram forum smoke, so it should not be treated as replacing the remaining Real behavior proof gate unless maintainers accept test proof for that gate.

Base reproduces the bug boundary

Base: origin/main at 3f590b48280e

I added a temporary failing regression test to a clean base worktree:

pnpm test extensions/telegram/src/draft-stream.test.ts -- -t "reproduction: does not retry forum message preview sends without thread when thread is not found"

Result: failed as expected. Base retries a forum/topic preview send without message_thread_id after Telegram returns 400: Bad Request: message thread not found.

Key failure:

AssertionError: expected "vi.fn()" to be called 1 times, but got 2 times
extensions/telegram/src/draft-stream.test.ts:199:29

That proves the pre-fix behavior still has a threadless retry path for explicit forum sends.

PR head passes the fixed behavior

Head: 54b7b0d1f842

The same behavior is covered by the committed PR test:

pnpm test extensions/telegram/src/draft-stream.test.ts -- -t "does not retry forum message preview sends without thread when thread is not found"

Result:

Test Files  1 passed (1)
Tests  1 passed | 32 skipped (33)
[test] passed 1 Vitest shard

So the current PR head proves base-fails/head-passes for the explicit forum send retry case: when a forum/topic send has a message_thread_id, this PR now fails closed instead of retrying into the group root.

Residual: I still have not run a live Telegram forum bot smoke against this PR head. The local tests prove the fallback bug boundary; they do not prove end-to-end production Telegram delivery into a real forum topic.

@clawsweeper re-review

Rebased this branch onto current upstream/main and addressed the P2 finding plus current-main CI guardrail failures:

• Direct/private Telegram topic sends now fail closed on message thread not found; no threadless retry for DM/direct sends.
• PR body has the required Real Behavior Proof fields and current tested versions/head SHA.
• Patched the inherited lint/type/contract/OpenGrep failures that showed up after rebase (src/media/fetch.ts, plugin runtime config scope, Matrix test runtime boundary, and the sessions-patch lint cleanup).

Local checks run after the update:

pnpm check:test-types
pnpm lint --threads=8
pnpm test extensions/telegram/src/send.test.ts extensions/telegram/src/draft-stream.test.ts src/infra/outbound/targets.test.ts src/cron/isolated-agent.direct-delivery-core-channels.test.ts src/infra/heartbeat-runner.ghost-reminder.test.ts src/cron/isolated-agent/session.test.ts src/cron/isolated-agent.delivery-awareness.test.ts src/cron/isolated-agent/delivery-target.test.ts
pnpm test src/plugins/contracts/deprecated-internal-config-api.test.ts src/plugins/contracts/plugin-sdk-package-contract-guardrails.test.ts
pnpm test src/plugins/registry.runtime-config.test.ts src/media/fetch.test.ts extensions/matrix/src/matrix/subagent-hooks.test.ts

I could not run local OpenGrep because opengrep is not installed in this environment, but the reported direct Response.arrayBuffer() finding in src/media/fetch.ts is removed.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/25816943869
• Updated: 2026-05-13T18:06:47.771Z

Added live Telegram Bot API proof to the PR body and linked a public redacted transcript:

https://gist.github.com/kesslerio/ed41189511d354a6e4fbe4470ec73bc8

What the proof exercises on PR branch head f515e5d36ac1166b955838c21489390dbfd9dbe2:

• valid non-General staging topic send keeps message_thread_id=39783 and succeeds
• invalid explicit non-General topic 987654321 fails with message thread not found after exactly one Bot API call, proving no threadless retry
• General topic send omits message_thread_id and succeeds chat-scoped

The proof uses the branch's sendMessageTelegram path with a real Telegram Bot API wrapper so the changed fallback policy is exercised against real Telegram transport without starting a second poller. The staging bot token could not access the group, so I used the production bot token for direct send-only proof; no polling was started.

The remaining live limitation is cron/heartbeat full-gateway proof. Existing focused tests still cover cron delivery context and heartbeat route reconstruction, while this live proof covers the transport-sensitive send fallback behavior that was blocking the PR.

@clawsweeper re-review

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26544992529
• Updated: 2026-05-27T23:39:50.979Z

Live Telegram forum-topic proof, head f515e5d36ac1166b955838c21489390dbfd9dbe2

I reran the topic-routing proof against a disposable OpenClaw staging gateway using @kesslerClawBot in a real Telegram forum group.

Environment:

OpenClaw PR head: f515e5d36ac1166b955838c21489390dbfd9dbe2
Gateway worktree: /tmp/openclaw-pr76920-merge
Staging group: -1003908474243
#General topic: 1
Non-General proof topic: 16
Bot: @kesslerClawBot

Command path used the PR's built Telegram runtime, sendMessageTelegram from dist/extensions/telegram/runtime-api.js, with the staging bot token loaded from local env and redacted from output.

Observed transcript:

head=f515e5d36ac1166b955838c21489390dbfd9dbe2
chat=-1003908474243
generalTopic=1
marker=pr76920-proof-1779918566238
[telegram] outbound send ok accountId=default chatId=-1003908474243 messageId=14 operation=sendMessage deliveryKind=text chunkCount=1
rootSend=ok messageId=14 chatId=-1003908474243
[telegram] outbound send ok accountId=default chatId=-1003908474243 messageId=15 operation=sendMessage deliveryKind=text chunkCount=1
generalTopicSend=ok messageId=15 chatId=-1003908474243 topic=1
[telegram] message failed: Call to 'sendMessage' failed! (400: Bad Request: message thread not found)
invalidTopicSend=failed_closed topic=999999
invalidTopicError=GrammyError: Call to 'sendMessage' failed! (400: Bad Request: message thread not found)
invalidTopicCheck=no_threadless_retry_observed

nonGeneralTopicProof=head=f515e5d36ac1166b955838c21489390dbfd9dbe2
nonGeneralTopic=16
nonGeneralMarker=pr76920-proof-topic16-1779919775720
[telegram] outbound send ok accountId=default chatId=-1003908474243 messageId=17 operation=sendMessage deliveryKind=text threadId=16 chunkCount=1
nonGeneralTopicSend=ok messageId=17 chatId=-1003908474243 topic=16

What this proves:

• Root chat-scoped send succeeded without a topic/thread id.
• #General topic 1 send succeeded and remained chat-scoped, matching Telegram's General-topic fallback behavior.
• Invalid explicit topic 999999 failed closed with message thread not found and did not retry threadless.
• Valid explicit non-General topic 16 sent successfully with threadId=16, proving topic-scoped delivery stays in the requested forum topic.

@clawsweeper re-review

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

Re-review progress:

• State: Complete
• Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/26541829110
• Updated: 2026-05-27T22:19:06.469Z

Heads up: this PR needs to be updated against current main before the new required Dependency Guard check can pass.