Add selected-thread delivery and cron-to-heartbeat conversion for automations

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #29179
• #28329
• #28922

Powered by Codex Action

Automation delivery should be a durable routing choice on the schedule. Store delivery mode, destination thread id, thread title, run id, last delivered message id, and conversion history from detached cron to selected-thread heartbeat.

Each run can then emit a receipt: created new thread, appended to selected thread, failed because destination missing, or rerouted by policy. That gives users one Morning Brief timeline without losing auditability for individual scheduled runs.

---

_Generated with ax._

Adding user-perspective signal. I have a persistent coordinator thread that I want scheduled checks to land in, instead of one new sidebar chat per run. The current split between detached cron and heartbeat makes the setup feel like an implementation detail.

For selected-thread delivery, the key requirements from my workflow are:

• choose an existing destination thread;
• keep the schedule, prompt, enabled state, and history while converting;
• append a run receipt to the selected thread: run id, status, delivery target, timestamp, and failure reason if the destination is unavailable;
• make the destination visible in the automation list/settings;
• preserve per-run auditability even if the human reading surface stays in one timeline.

This would make weekday command-center style automations much easier to trust and maintain.

Automation delivery should be a durable routing choice on the schedule. Store delivery mode, destination thread id, thread title, run id, last delivered message id, and conversion history from detached cron to selected-thread heartbeat. Each run can then emit a receipt: created new thread, appended to selected thread, failed because destination missing, or rerouted by policy. That gives users one Morning Brief timeline without losing auditability for individual scheduled runs. _Generated with ax._

@Necmttn I agree that delivery should be modeled as durable routing metadata on the automation/schedule, not as an implicit side effect of cron vs heartbeat. The receipt idea is especially important: each run should make it clear whether it created a new thread, appended to the selected thread, failed because the destination was unavailable, or was rerouted by policy.

Adding user-perspective signal. I have a persistent coordinator thread that I want scheduled checks to land in, instead of one new sidebar chat per run. The current split between detached cron and heartbeat makes the setup feel like an implementation detail. For selected-thread delivery, the key requirements from my workflow are: choose an existing destination thread; keep the schedule, prompt, enabled state, and history while converting; append a run receipt to the selected thread: run id, status, delivery target, timestamp, and failure reason if the destination is unavailable; make the destination visible in the automation list/settings; * preserve per-run auditability even if the human reading surface stays in one timeline. This would make weekday command-center style automations much easier to trust and maintain.

@TyronSamaroo yes, this is the user-facing problem exactly. The important bit is that the “one Morning Brief timeline” should not come at the cost of auditability. I still want per-run history/status, but I don’t want every run to become a new sidebar conversation.

I hit exactly this problem with a real daily automation on Codex Desktop.

A daily skill-sync watch was configured as a detached cron job. Each run created a separate sidebar conversation, even though I wanted every result to append to one persistent, pinned thread.

Impact:

• 48 automation conversations accumulated between late May and mid-July.
• 44 duplicate conversations were still active in the main thread list.
• Cleaning them up required archiving each thread through the app API.
• Converting the automation required manually changing it from cron to heartbeat and assigning a target_thread_id.
• The automation UI did not expose a reliable way to select the destination thread or convert the existing schedule.
• The app automation update API also stalled during the attempted conversion.

This should be a first-class routing choice on every recurring automation:

• New thread per run
• Continue in selected existing thread

The destination should remain visible and editable, and conversion should preserve the schedule, prompt, enabled state, and run history.

Routing recurring background jobs back to a fixed channel/thread is a basic workflow in tools such as OpenClaw. Its absence makes migration to Codex much more difficult and creates substantial conversation-list clutter.