Repository navigation
[Feature]: A persistent thread per automation, kept out of the active sidebar #16485
Description
The use case
I run several recurring agent automations with schedule_task. Each one is bound to its own thread (bindToCurrentThread: true), so every run of an automation adds to the same thread. They all follow the same pattern: check something often, act only when there is something to do.
- Hourly issue watcher: reads new issue comments and picks up requests aimed at the agent, such as "write a plan for this" or "implement the approved plan".
- Hourly PR review check: looks for PRs that are waiting on a review and reviews them.
- Auto-labeler and tidier: triages new issues, adds labels, links duplicates and flags stale branches.
- Daily digest: a short report on what changed in open issues and PRs since yesterday.
- Daily error triage: reviews new production errors and opens or updates an issue only when the evidence is strong.
Most runs find nothing and post one line. A few find real work.
What goes wrong
Every run starts a turn, so each automation thread keeps coming back to the top of the active list. They end up mixed in with the threads I actually work in. Snooze doesn't stick (#14625), and an agent can't settle its own thread while its run is active (#13630). I end up settling quiet runs by hand, which defeats the point of an automation that should only get my attention when something matters.
Proposal: treat these as persistent automation threads
- A collapsed "Automations" section in the sidebar holds every thread bound to a scheduled task. Each row shows the task name, last and next run, and an unread dot. Quiet runs stay there.
- A run surfaces only when it asks to. The agent marks the thread unread, or the run fails. Everything else stays in the section.
- Larger work moves to a fresh thread. When a run finds a real task (a plan to write, a PR to implement, a review to do), it starts a new top-level thread for it with
t3_thread_launchand leaves one line plus a link in the automation thread. The automation thread stays a clean, readable log of runs, and the actual work gets its own normal thread with its own worktree, PRs and notifications. - Lineage: threads started this way show which automation started them, and the automation thread lists the threads it has launched.
Related
- [Feature]: Auto Settle, hide a running thread and settle it silently when it's done #13630: agent settles its own thread once its run is done (would fix the quiet-run case per thread)
- [Feature]: Let me hide agent-to-agent threads: a snooze that holds until its time, whatever activity happens #14625: snooze is cleared by any new turn
- [Feature]: Skip scheduled task occurrences when the bound thread is already running #16393: skip runs while the bound thread is busy
- [Feature]: Thread-bound scheduled tasks should optionally use the thread’s current agent/model #15821: thread-bound tasks using the thread's current model
Reacted by Samuel Chreno and Matt Stone
Activity
iamtoled commentedon Oct 9, 2026
Same problem here. A smaller version of point 2 could be a useful first step.
I settle a thread after reading the report from its recurring task. The next run un-settles it right away, even when that run has nothing to report, so the thread is back in the active list on every run.
Where it happens (main at
7a2b1c72):ThreadManagementService.sendToThread, withscheduledTaskIdset (ScheduledTaskService.ts#L817-L830).message.dispatch.dispatchMessageclearssettledOverrideand the snooze for every message, whatever started it (Orchestrator.ts#L4562-L4605).The message already carries
scheduledTaskId, so the orchestrator can tell a scheduled run from a message I typed.Smallest useful change: when a message comes from a scheduled task, leave a settled or snoozed thread where it is. Bring it back only if the run asks for attention (the agent marks the thread unread, or opens an approval or question) or if the run fails. That gets point 2 of this proposal without waiting for the Automations section.
n0mahd commentedon Oct 10, 2026
I'd like to propose a smaller first step toward this, covering tasks that start a fresh thread per run (
bindToCurrentThread: false). Those currently add one sidebar thread per run.Proposal: a per-task Run in the background switch. When it's on, each run is still a normal thread (readable, searchable, linkable, notifications unchanged), but it stays out of the sidebar and mobile thread lists. The task's row in Settings → Scheduled tasks gets an Open last run link. Agents can set it through
schedule_task/update_scheduled_task.Scope: it doesn't add the Automations section or the persistent-thread model, and thread-bound tasks are unchanged, so the settle/snooze points here (#13630, #14625) stay separate. It would fit under an Automations section later if you go that way.
I have a working implementation with before/after screenshots in #17893. Maintainers, is this direction and scope acceptable? I'm happy to reshape it or close the PR if you'd rather go another way.