›_ Codex Issues
Codex Issues / #30515

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

Open 💬 4 comments Opened Jun 29, 2026 by kevinsun7083-cmd
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29184
  • #29179

Powered by Codex Action

whatthecodemean · 1 month ago

Additional Windows repro evidence (26.715.10079.0)

I can reproduce Issue 1: automation run threads pollute the normal thread list on the current Microsoft Store Windows build.

Environment
  • Codex Desktop package: OpenAI.Codex_26.715.10079.0_x64__2p2nqsd0c76g0
  • OS: Windows 11 Pro, version 10.0.26200, x64
  • Automation type: standalone local cron automation assigned to a project
  • Model used in the live repro: GPT-5.3-Codex-Spark
Reproduction
  1. Create or enable a standalone local cron automation assigned to a project.
  2. Let the automation complete normally.
  3. Open Scheduled and confirm that the run is present there.
  4. Open the normal project conversation/task list.
  5. The same completed automation run is also visible as a regular project thread, so repeated runs accumulate alongside user-created work.
Expected behavior

Standalone automation runs should be surfaced in Scheduled / the review queue, without also accumulating in the normal project thread list unless the user explicitly opens, pins, or promotes a run.

This matches the current product documentation, which says standalone scheduled tasks report their results in Scheduled: https://learn.chatgpt.com/docs/automations

Local state evidence

The same-machine state history shows a behavior change:

  • Older automation runs were finalized as status = ARCHIVED with archived_reason = auto.
  • Current completed runs are finalized as status = PENDING_REVIEW with archived_reason = NULL.
  • Manually archiving one of the current runs changes it to ARCHIVED / auto, removes it from the normal project list, and keeps it available under Scheduled history.
  • Setting the native notification policy to failed_runs_only only marks successful runs as read; it does not archive them or prevent them from entering the normal project list.

Inspection of the installed desktop bundle also suggests that the regular local thread catalog and live project-list filters special-case pull-request automation threads, but do not exclude threads whose threadSource is automation. That is consistent with the observed UI behavior.

Suggested verification for a fix
  1. Complete several standalone cron runs in the same project.
  2. Confirm each run remains accessible from Scheduled.
  3. Confirm completed automation runs do not appear in the normal project thread list by default.
  4. Confirm failed/waiting runs still surface for review.
  5. Confirm manually opened or pinned runs remain accessible as intended.

No project paths, automation names, account identifiers, or thread IDs are included in this report.

whatthecodemean · 1 month ago

A quick update after support asked whether this survives an app restart.

Codex has since restarted and updated from Windows build 26.715.10079.0 to 26.721.4979.0. The five runs from the earlier reproduction are now ARCHIVED with archived_reason = auto, and they are no longer in the ordinary local thread catalog.

That is encouraging, but it does not prove the bug is fixed: those older samples were already archived, so they cannot tell us whether a still-unarchived automation run would remain in the normal project list after a restart. I will check the next normal standalone run on the current build rather than create an artificial automation just for this test.

The distinction that matters here is simple: a new chat for each standalone run is expected. The problem is the same run appearing both in Scheduled and in the ordinary project task list. Switching to a heartbeat is not an equivalent workaround for someone who wants independent scheduled runs without filling the regular task list.

UltraDD · 24 days ago

Additional selective-classification repro on Windows 26.727.6591.0

I reproduced a narrower intermittent variant on a newer Microsoft Store Windows build.

Environment
  • Codex Desktop package: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
  • Bundled CLI/session version: 0.146.0-alpha.9.2
  • Windows, standalone local cron automations assigned to the same project and working directory
Observed behavior

Four materially identical project-scoped cron runs started within the same roughly ten-second window. All four:

  • had thread_source = automation;
  • were registered in the local automation-run state;
  • produced valid inbox-item directives;
  • appeared in Scheduled as unread/pending-review runs.

However, only one run also appeared in the ordinary Projects conversation/task list. The other runs remained confined to Scheduled.

The affected run completed at 09:42:42 local time. The first user interaction with that thread did not start until 09:54:05, so opening, replying to, or manually promoting the thread did not cause it to enter Projects.

Why this seems distinct

This does not look like every standalone run being intentionally included in the normal list. It appears to be selective and timing-dependent: one run was rendered/indexed as a normal project conversation while equivalent runs were correctly treated as Scheduled-only.

The retained local state confirms that the affected thread was still recognized as an automation run, so this may be a sidebar classification/refresh race rather than only an archiving-policy issue.

Expected behavior

When “Show Scheduled” is disabled, all equivalent standalone automation runs should be treated consistently and remain out of the normal project conversation list unless the user explicitly opens, pins, or promotes one.

No project paths, automation names, account identifiers, or thread IDs are included here.