Create cron-main-channel-targeting.md#91104
Conversation
openclaw-barnacle
Bot
added
size: XS
triage: low-signal-docs
|
Thanks for the contribution. I reviewed the branch, and this PR is not a good landing base for OpenClaw. Close: the useful cron targeting limitation is real, but this PR is not a mergeable fix because it only adds an unreferenced top-level proposal file and would not change cron routing behavior. So I’m closing this PR rather than keeping an unmergeable branch open. A new narrow PR that carries only the useful part is welcome. Review detailsBest possible solution: Close this proposal branch and continue the API discussion in the canonical cron output-routing issue, then accept a future focused implementation PR with schema, runtime, CLI/docs, tests, and redacted multi-channel proof. Do we have a high-confidence way to reproduce the issue? No live high-confidence reproduction was run. Source inspection does show the current limitation: main-session cron rejects non-webhook channel delivery config and uses heartbeat Is this the best way to solve the issue? No. A top-level proposal file is not the best fix; maintainers should first choose the cron output-routing API, then review a focused implementation with real multi-channel proof. Security review: Security review cleared: The diff adds only Markdown proposal text and does not introduce executable code, dependencies, workflows, or secret-handling changes. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 37e3e895b020. |
clawsweeper
Bot
added
the
rating: 🌊 off-meta tidepool
clawsweeper
Bot
added
rating: 🧂 unranked krab
|
ClawSweeper applied the proposed close for this PR.
|
1 participant
Summary
What problem does this PR solve?
Cron jobs using sessionTarget: main have no way to specify a target delivery channel. For agents bound to multiple Slack channels, the output channel is non-deterministic — it depends on which channel last had activity in the main session. This makes reliable, channel-specific cron delivery impossible without switching to isolated mode.
Why does this matter now?
Multi-channel agents are a common pattern (e.g. a single agent serving several account channels). Without channel targeting in main mode, operators must choose between reply continuity (main) and delivery guarantees (isolated) — there is no option that provides both.
What is the intended outcome?
Support a to: field (or equivalent channel-targeting parameter) in sessionTarget: main cron job configuration, so the output is always delivered to the specified channel regardless of session history.
What is intentionally out of scope?
Changes to isolated mode behavior; changes to how replies are routed after delivery.
What does success look like?
A cron job configured with sessionTarget: main and a to: field consistently delivers its output to the specified channel, even when the agent is active in other channels.
What should reviewers focus on?
Whether the proposed to: parameter is the right API surface, or whether an alternative (e.g. delivery.channel unified across both session targets) is preferred.
───
Linked context
Which issue does this close?
Closes # (open a matching issue first if one doesn't exist, then link it here)
Which issues, PRs, or discussions are related?
Related # (link any Discord discussion or forum thread)
Was this requested by a maintainer or owner?
No — this is a community-raised limitation discovered in production use of multi-channel agents.
───
Real behavior proof (required for external PRs)
• Behavior or issue addressed: Cron job with sessionTarget: main delivering to the wrong Slack channel when agent is active in multiple channels
• Real environment tested: Self-hosted OpenClaw on AWS EC2, multiple Slack channels bound to a single agent
• Exact steps or command run after this patch: N/A — this is a feature proposal PR, no implementation patch included
• Evidence after fix: N/A
• Observed result after fix: N/A
• What was not tested: Full implementation — this PR proposes the feature; implementation and testing would follow maintainer feedback
• Proof limitations or environment constraints: This is a design/feature proposal. Real behavior proof will be added once an implementation approach is agreed upon.
───
Tests and validation
Which commands did you run? N/A — proposal only
What regression coverage was added or updated? None at this stage
What failed before this fix, if known? Cron output delivered to wrong channel in multi-channel agent setup
If no test was added, why not? No implementation yet — this PR is to propose and discuss the feature before writing code
───
Risk checklist
Did user-visible behavior change? No (proposal only)
Did config, environment, or migration behavior change? No
Did security, auth, secrets, network, or tool execution behavior change? No
What is the highest-risk area? Session routing logic for main mode cron jobs
How is that risk mitigated? To be determined by maintainers during design review
───
Current review state
What is the next action? Maintainer feedback on whether to: in main mode is the right approach, or if an alternative API is preferred
What is still waiting on? Maintainer input before any implementation begins
Which bot or reviewer comments were addressed? None yet — initial submission