›_ Codex Issues
Codex Issues / #28329

Automations need a silent-success mode to avoid flooding long-lived projects with threads

Resolved 💬 2 comments Opened Jun 15, 2026 by hxsy2018-figoxing Closed Jun 25, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

In a long-lived Codex desktop project, every scheduled automation run creates a visible thread/session, even when the run succeeds and there is nothing useful to report.

My project has four routine runs per day:

  • one daily content-generation automation
  • three daily review/status scans

This creates four low-value threads every day. Over time, the project timeline becomes dominated by automation runs, making important human conversations difficult to find.

Changing the automation prompt to return only a one-line success message reduces the content, but it does not prevent the thread from being created. A successful no-op scan still creates a new visible session.

Expected behavior

Automations should support configurable notification and thread-creation policies, such as:

  1. Only on failure or matching condition: create a visible thread only when the run fails or a configured condition is met.
  2. Silent success: record successful runs in an automation run log without creating a project thread.
  3. Always notify: preserve the current behavior.
  4. Optionally, show automation runs in a separate log/history view rather than mixing them with human project conversations.
  5. Allow automatic hiding, collapsing, or archiving of routine automation-created threads.

Actual behavior

Every automation execution creates a visible project thread regardless of whether it succeeds, fails, changes anything, or has useful output.

Why this matters

Scheduled automations are especially useful for long-running projects, but those are also the projects most harmed by accumulating multiple routine sessions every day. The current behavior makes automation and conversation history compete for the same timeline.

Workaround

The only effective workaround is to move the schedule outside Codex, run it as an operating-system background task, write results to a local table/log, and disable the Codex automation. This loses the convenience of managing the schedule inside Codex.

Suggested solution

Add a notification policy to automation settings:

  • Always create thread
  • Create thread only on failure
  • Create thread only when output/changes exist
  • Never create thread; log run only

Also provide a dedicated automation run-history view for inspecting normal and failed runs.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27022

Powered by Codex Action

aidawilliam41-ops · 1 month ago

I can reproduce what looks like a Windows Desktop regression of the silent-success behavior described here.

Environment

  • Windows 11
  • ChatGPT/Codex Desktop 26.707.3748.0
  • Local scheduled task attached to an existing chat

Reproduction

  1. Create a scheduled/heartbeat task that performs a read-only no-op check.
  2. When there is nothing to report, return exactly:

<heartbeat><automation_id>buyer-approvals</automation_id><decision>DONT_NOTIFY</decision><message>dispatch queue empty</message></heartbeat>

  1. Let the task run repeatedly.

Observed

  • The local trace contains 72 heartbeat inputs and 72 assistant outputs between 2026-07-09 10:02:25Z and 11:36:30Z.
  • Every output used the DONT_NOTIFY decision shown above.
  • Despite that, the chat UI rendered repeated visible dispatch queue empty results.
  • The Scheduled counter also increased during the run (captured locally growing from 14 to 21).

Expected

  • A DONT_NOTIFY/no-op result may remain in run history for auditability, but it should not create a visible chat message, unread badge, or a new user-attention item.

Impact

  • A monitoring task that has no user-relevant result floods the working conversation and Scheduled surface.
  • Users cannot distinguish a real event from a successful empty check.

Important separation

  • The one-minute polling cadence was an agent/configuration mistake and is not being reported as a Codex bug.
  • The product concern is narrower: the suppression directive was present on every run, but the Desktop UI still surfaced the result.

Workaround

  • Remove high-frequency heartbeat pollers and use a direct local runner for interactive commands.
  • Keep scheduled tasks event-oriented and low-frequency until silent no-op behavior is confirmed.

Could you confirm whether the fix for #28329 is expected to cover heartbeat-style outputs on Windows Desktop, and reopen this issue if the behavior above is a regression?