[Feature]: A persistent thread per automation, kept out of the active sidebar

[TimPeterNL]

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

1. 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.
2. A run surfaces only when it asks to. The agent marks the thread unread, or the run fails. Everything else stays in the section.
3. 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_launch and 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.
4. 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

[iamtoled]

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):

• The scheduler sends its prompt with ThreadManagementService.sendToThread, with scheduledTaskId set (ScheduledTaskService.ts#L817-L830).
• That becomes a message.dispatch. dispatchMessage clears settledOverride and 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]

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.

[jvitormelo]

+1, same setup here. I run 6 scheduled tasks bound to 3 threads (an hourly error-triage/autofix loop, scraping health checks 3×/day, a 6h focus reminder). Today I keep those 3 threads pinned, since pinning is the only stable place for them, so the pinned block has turned into my makeshift "Automations" section. A collapsed Automations section as proposed here is exactly what I'm missing.

Until then, I opened #21908 for a much smaller step: a divider after the last pinned thread, so that makeshift section is at least visually separated from the threads I'm actively working in.

[dkritarth]

I have a similar need for long-running HPC experiments. I ask a main thread to create a separate monitoring thread, often using a cheaper model. While a job is queued, the monitor checks it on a 30-minute schedule; once it starts, the monitor checks its health and progress.

Each scheduled check moves the monitoring thread between Working, the inbox, and Settled. Most checks don't need my attention, but the thread keeps returning to the sidebar.

I'd like to mark a thread as a background monitor, either directly or with a tag such as hpc-monitor. It should keep running and remain searchable by tag, while staying out of the normal inbox and Working list through routine checks. I should be able to open it or remove the tag whenever I want.

When the monitor finds a problem or needs my input, it should have an explicit way to bring the thread back to my attention. Routine activity and successful checks should not do that.

Searchable tags would also be useful for finding related monitors, as discussed in #6902. The key behavior for this use case is that hiding a thread must not stop its scheduled work.

[Azarattum]

Note

🤖 GPT-6.1 Sol responding on behalf of Azarattum

A draft implementation is available in PR #31331, with before/after screenshots. It adds a persistent Background choice for threads and scheduled tasks, covering both reused threads and fresh threads per run. Quiet checks stay out of Active; failures, questions, approvals, and explicitly reported results surface. The agent and schedule keep running. This proposes Background placement rather than an automation-only lifecycle; it does not add automation lineage or child-thread grouping. Maintainer approval of direction and scope is still pending.

[audvin]

+1, with one more data point. We run six hourly scheduled tasks bound to six long-lived threads (one supervisor and five area "owners"). On a typical hour every one of them finds nothing and replies with one line, e.g. "Quiet (7:34 AM PT)". Each of those runs puts the thread back in Active and plays the completion sound, so the sound fires several times an hour for runs that need no attention, and the real ones get lost in it.

What we tried: ending a quiet run with no reply doesn't work. The agent harness re-prompts an empty final message, so every run has to post at least one line. That makes an opt-out on the task side the only way to keep quiet runs quiet.

What would solve it for us, in order of preference:

1. The Background option from feat(threads): keep recurring work in Background until it needs attention #31331: quiet scheduled runs don't move the thread to Active and don't play a sound; a run still surfaces when it fails, asks a question or needs approval.
2. A per-thread (or per-task) mute for the completion sound, independent of sidebar placement.
3. The gate command from Scheduled tasks: skip a run with a gate command and pass its output to the prompt #33242, so a run whose cheap check finds nothing never starts.

Happy to test #31331 on our setup if that helps.