-
-
Notifications
You must be signed in to change notification settings - Fork 80.7k
[Feature]: Allow topic/forum cron deliveries to use main-session announce/agent-turn flow instead of forced direct delivery #38573
Copy link
Copy link
Open
Labels
P2Normal backlog priority with limited blast radius.Normal backlog priority with limited blast radius.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.enhancementNew feature or requestNew feature or requestimpact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.Session, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Description
Metadata
Metadata
Assignees
Labels
P2Normal backlog priority with limited blast radius.Normal backlog priority with limited blast radius.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.enhancementNew feature or requestNew feature or requestimpact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.Session, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.
Type
Fields
Priority
None yet
Summary
Add a config or per-cron option to let topic/forum targets use the same announce → main-agent-turn behavior that currently works in DMs, instead of always forcing direct delivery.
Problem to solve
Right now isolated cron jobs targeting topic/forum chats are forced into direct delivery when the resolved target has a threadId. That means cron output is sent straight to the channel and bypasses the main-session announce/agent-turn path.
This creates a behavior mismatch between DM and group-topic sessions:
• In DMs, isolated cron output can go through the main-session announce path, which lets the main agent rewrite/summarize the result in its own voice and decide what to send.
• In topic/forum sessions, cron delivery is forced to direct-send, so the result bypasses that rewrite/handoff behavior.
This is a problem for users who want:
• isolated execution
• main-agent judgment/rewrite before posting
• consistent behavior across DM and topic/group sessions
• continue to chat with the cron output
Current behavior is especially confusing because subagent/announce fixes for group/topic sessions exist, but cron delivery still hardcodes direct delivery for thread/topic targets.
Relevant current code path:
src/cron/isolated-agent/delivery-dispatch.ts
Current logic:
And the comment explicitly says:
That hardcoded branch makes this impossible to configure today without a source patch.
Proposed solution
Add an explicit config or cron-job-level option to control how text-only cron completions are delivered for thread/topic targets.
Possible API shapes:
Option A — per-job cron option:
{ "delivery": { "mode": "announce", "channel": "telegram", "to": "-1003508166716:topic:1", "threadDeliveryMode": "announce-agent-turn" } }Option B — top-level cron/job option:
{ "sessionTarget": "isolated", "payload": { "kind": "agentTurn", "message": "..." }, "wakeMode": "now", "delivery": { "mode": "announce", "channel": "telegram", "to": "-1003508166716:topic:1" }, "completionRouteMode": "agent-turn" }Option C — global config default with per-job override:
{ "agents": { "defaults": { "cron": { "topicTextDeliveryMode": "direct" | "announce-agent-turn" } } } }Desired semantics:
• Keep current direct-send behavior as the default for backward compatibility.
• Allow users to opt in to “announce/main-agent-turn” behavior for topic/forum targets.
• Only apply this to text-only cron completions.
• Structured payloads (media/files/cards/etc.) can still use direct delivery.
• If announce/agent-turn fails, fallback behavior should be explicit and configurable:
• fail closed
• fallback to direct send
• or best-effort
This would make topic/forum cron behavior match DM behavior when users explicitly want that.
Alternatives considered
• Sending cron output to DM instead of the topic: works, but defeats the point of routing the workflow to the group/topic.
• Using a separate helper cron/systemEvent to force a later main-session turn: works as a hack, but adds complexity and timing fragility.
• Hardcoding style instructions into cron prompts: only treats the symptom and does not restore the missing main-agent rewrite/handoff behavior.
• Patching local source: works, but users on trunk/Nix/module setups should not need custom forks for this.
Impact
Affected:
• users running isolated cron jobs to Telegram forum topics / threaded group targets
• likely other channels with thread/topic semantics, not just Telegram
Severity:
• medium to high depending on workflow
• not a total blocker, but it breaks a very useful pattern: “run isolated, then let the main agent decide how to present it”
Frequency:
• always, for topic/forum cron targets under current code
Consequence:
• cron output in topics bypasses main-agent rewrite/judgment
• inconsistent behavior between DM and topic sessions
• more robotic/raw channel output
• users must choose between correct routing and better delivery behavior
• forces ugly workarounds or local patches
Evidence/examples
Observed current code on trunk:
• latest checked main commit still contains:
and the comment:
That explains the current behavior, but it also means there is no config path to opt into DM-like behavior for topic targets.
Additional information
• issue #34160 / follow-up work around group/topic announce-triggered main turns
• cron delivery still appears to have a separate topic-specific direct-delivery override