Codex worktree automations run but archive output without surfacing results; chat heartbeat works

Open 💬 2 comments Opened May 23, 2026 by wdvf4vhh5v-web
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.519.41501 (CFBundleVersion 3044)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

  1. Open Codex Automations and create a worktree automation in a local project.
  2. Use a very small prompt, for example:
Automation smoke test.
Read only README.md and one local project file.
Do not edit files.
Reply with: Automation smoke test passed.
  1. Schedule it to run a few minutes later, or use a simple daily schedule near the current time.
  2. Wait for the UI to show Last ran.
  3. Inspect the local scheduler database:
sqlite3 ~/.codex/sqlite/codex-dev.db "select id,name,status,rrule,next_run_at,last_run_at,cwds from automations order by name; select automation_id,status,thread_title,source_cwd,inbox_title,inbox_summary,created_at,updated_at from automation_runs order by created_at desc limit 10;"
  1. The worktree automation shows last_run_at populated and an automation_runs row with status ARCHIVED, but no useful output appears in the UI.
  2. Create a chat-targeted heartbeat automation to a known chat. In my test, that heartbeat did visibly post into the target chat, which suggests dispatch/result routing differs by automation type.

What steps can reproduce the bug?

  1. Open Codex Automations and create a worktree automation in a local project.
  2. 2. Use a very small prompt, for example:
Automation smoke test.
Read only README.md and one local project file.
Do not edit files.
Reply with: Automation smoke test passed.
  1. Schedule it to run a few minutes later, or use a simple daily schedule near the current time.
  2. 4. Wait for the UI to show Last ran.
  3. 5. Inspect the local scheduler database:
sqlite3 ~/.codex/sqlite/codex-dev.db "select id,name,status,rrule,next_run_at,last_run_at,cwds from automations order by name; select automation_id,status,thread_title,source_cwd,inbox_title,inbox_summary,created_at,updated_at from automation_runs order by created_at desc limit 10;"
  1. The worktree automation shows last_run_at populated and an automation_runs row with status ARCHIVED, but no useful output appears in the UI.
  2. 7. Create a chat-targeted heartbeat automation to a known chat. In my test, that heartbeat did visibly post into the target chat, which suggests dispatch/result routing differs by automation type.

What is the expected behavior?

After a worktree automation runs, the result should be visible and reviewable somewhere in the app: the automation detail page, previous run history, an inbox item, the project/thread, or a clearly linked run artifact.

If a run is archived, the UI should still make clear whether it succeeded, failed, or produced no output, and should expose the assistant response or failure reason.

At minimum, a simple worktree automation that says Reply with: Automation smoke test passed should surface that exact response or a clear error.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23895
  • #24019
  • #24096

Powered by Codex Action

whatthecodemean · 1 month ago

Related but distinct current Windows evidence may help define the intended invariant here.

On Codex Desktop 26.715.10079.0 for Windows, standalone local cron runs now complete as PENDING_REVIEW and remain visible in the normal project thread list. Manually archiving one of those runs removes it from the normal project list but keeps the run and its result accessible in Scheduled history.

That suggests the desired behavior should separate these two concerns:

  1. automation-generated run threads should not accumulate in the normal project conversation list; and
  2. archiving an automation run must not make its result disappear from the Automation/Scheduled review UI.

The inverse current behavior (unarchived runs polluting the normal list) and additional Windows evidence are tracked in #30515, especially https://github.com/openai/codex/issues/30515#issuecomment-5059601325.

I am not claiming the worktree result-routing failure in this issue has the same root cause. The shared product invariant is that automation lifecycle state and review visibility should be handled independently.