Show automations targeting a thread in its Info panel #5554

The workflow

An agent creates an automation targeting an existing conversation. Before its first run, the user wants to see which future actions are scheduled to arrive in that conversation, without leaving the thread to search the global Automations view.

What happens today

The reporter has to open the global Automations view to find the schedule; it is not visible in the target thread's Info panel before the first run.

This is a feature request based on the reported workflow and a read-only source inspection at 05771e3c82404328854468f0fff7f0f8203e2076. The installed app was not independently reproduced or modified, and no automation was run. This is not a claim of a verified runtime regression.

Source evidence:

• ThreadMetadataContent renders metadata, related threads, commits/changes, and thread storage, with no automation section.
• PluginAppSlots provides separate thread panel actions and header actions, but no section inside Info.
• Automation list input currently filters by project only.
• Existing editor navigation already supports a project/automation edit route.

What you would expect

Add a compact Automations section immediately after the thread's main metadata, before related threads, commits, and thread storage:

• Hide it when no automations target the thread.
• Show the total count and up to three entries, followed by “Show N more”.
• Display each automation's name, scheduling status, and next run time.
• Open the existing automation editor when an entry is selected.
• Update after creation, editing, pausing, resuming, and deletion without requiring a run or page reload.

Membership should use automation.execution.targetThreadId. createdByThreadId identifies where an automation was created and should not automatically include it: its future work may run elsewhere. Completed one-shot automations should retain their existing lifecycle labels rather than appear paused.

Context and alternatives

A possible implementation is one narrowly scoped experimental slot in the thread Info panel, with Automations owning the query and section content. Existing Info components, automation realtime events, and editor navigation can be reused through the appropriate shared component boundary. The list API would need a server-side target-thread filter, also exposed through the CLI. This is an implementation proposal for discussion, not a request for a general panel-layout framework.

Using the existing thread panel action would require opening another tab and would not provide the requested visibility inside Info. Hard-coding the Automations model and RPC into core would weaken the existing plugin ownership boundary.

Related work, distinct from this request:

• Show automation prompts as compact timeline rows #4763 (merged) adds compact timeline rows for automation prompts after execution, rather than showing schedules before the first run.
• Automation runs are spawned as siblings of the thread that created them #3060 (closed) concerns the parent relationship of spawned runs to the creator thread.
• Improve automations browsing, notification controls, and failed target recovery #4447 (closed, unmerged) concerns automation browsing, notification controls, and failed-target recovery.

Open and closed issue searches for automation/thread Info, automation panels, and target-thread automations found no exact match. No implementation or PR has been created; this issue seeks feature/UI sign-off first.

Investigation source: local BB conversation thr_bp3gpw9zg9 (not publicly accessible); the investigation's relevant findings and exact source permalinks are included above.

Does this placement and scope fit the intended direction for thread Info and plugin extensions?

Checks

• I searched open and closed issues for the same request.
• If an agent wrote this, the body ends with > AGENT GENERATED.

AGENT GENERATED