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?
- Open Codex Automations and create a worktree automation in a local project.
- 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.
- Schedule it to run a few minutes later, or use a simple daily schedule near the current time.
- Wait for the UI to show
Last ran. - 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;"
- The worktree automation shows
last_run_atpopulated and anautomation_runsrow with statusARCHIVED, but no useful output appears in the UI. - 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?
- 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.
- Schedule it to run a few minutes later, or use a simple daily schedule near the current time.
- 4. Wait for the UI to show
Last ran. - 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;"
- The worktree automation shows
last_run_atpopulated and anautomation_runsrow with statusARCHIVED, but no useful output appears in the UI. - 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_
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Related but distinct current Windows evidence may help define the intended invariant here.
On Codex Desktop
26.715.10079.0for Windows, standalone local cron runs now complete asPENDING_REVIEWand 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:
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.