Codex App automations clutter main thread list and lose recurring task intent

Summary

Codex App cron automations currently create a new standalone conversation/thread for each run and surface those run threads directly in the normal main conversation list. For frequent daily automations, this heavily clutters the user's thread list with one-off automation run conversations.

There is also a recurring reliability issue where scheduled automation prompts are repeatedly interpreted incorrectly across runs, especially when a workflow has distinct preparation and publishing windows. The automation tends to forget or blur the intended temporal semantics, such as treating a preparation run as a publish run, targeting the wrong date, or failing to preserve the difference between "prepare tomorrow's package" and "publish/confirm today's package".

Environment

• Codex App desktop
• Windows
• Local cron automations
• Multiple recurring automations in the same project/workspace
• Automations use kind = "cron" with local execution

Issue 1: Automation run threads pollute the normal thread list

Current behavior

Each cron automation run creates a standalone thread titled like an automation run, for example:

• Automation: <automation name>
• Automation ID: <id>
• Last run: ...

These one-off run threads appear in the normal user conversation list alongside real manually-created conversations. With several daily automations, the sidebar quickly becomes dominated by automation-generated one-off threads.

Moving the automation's working directory into a project/workspace does not appear to keep the generated run threads scoped inside a project-only automation history. They still appear in the main thread list.

Expected behavior

Automation runs should not pollute the user's normal conversation list by default. Prefer one or more of:

• Store automation runs under a separate "Automation history" area.
• Group run history under the parent automation.
• Auto-archive automation run threads after completion unless pinned or failed.
• Provide a setting: "Show automation runs in main thread list".
• If an automation belongs to a project/workspace, keep its generated run records scoped to that project/workspace instead of showing them as global conversations.

User impact

Frequent daily automations create dozens of visible one-off conversations and make it difficult to find normal human conversations. The user has to periodically bulk archive automation runs manually.

Issue 2: Recurring task intent drifts or is misunderstood across scheduled runs

Current behavior

For recurring scheduled workflows with multiple time windows, Codex repeatedly misunderstands the intended schedule semantics even when the automation prompt is explicit. Examples of the intended semantics:

• 13:00 run: prepare tomorrow's 08:00 release package. Do not publish at 13:00.
• 06:00 run: pre-release risk check for today's 08:00 package.
• 08:00 run: publish or confirm today's prepared package. Do not regenerate content unless no valid package exists.
• 08:10 run: post-release closure check for today's 08:00 release.
• 13:10 / 13:50 runs: process-supervision checks for the next day's package, not same-day publishing.

Despite these distinctions being written in the automation prompts, the automated runs repeatedly require extra corrective wording because the agent may:

• Treat a preparation window as a publishing window.
• Target the wrong date, such as preparing/publishing same-day when the task is for next-day package preparation.
• Restart or regenerate work when it should only confirm existing prepared/published state.
• Fail to consistently preserve the difference between scheduler role, watchdog role, preparation role, publishing role, and post-release verification role.

Expected behavior

Codex automations should reliably preserve cron schedule semantics and task intent across runs. Recurring automation execution should treat the schedule and the prompt as stable operational context, especially date/time targets and "prepare vs publish vs verify" distinctions.

Possible improvements:

• Provide first-class schedule context variables, e.g. scheduled_run_time, actual_run_time, target_date, timezone, and automation_id.
• Make cron automations include a structured system message with the exact scheduled time and current timezone.
• Add an automation-level "run type" or "phase" field so agents can use structured metadata instead of relying only on long natural-language prompts.
• Add validation/warnings when multiple automations have similar names but different temporal responsibilities.
• Provide a way for an automation to persist and enforce invariants, such as "this automation never publishes" or "this automation only confirms an existing package".

Why this matters

For real operational workflows, automations are not just reminders. They are recurring production processes. If every run creates visible noise in the main chat list and the agent repeatedly misinterprets time-window responsibilities, the automation system becomes hard to trust and expensive to maintain.

Suggested severity

Medium to high for users running daily production automations. The clutter issue is a UX/product defect; the recurring intent drift is a reliability defect for scheduled operations.