Codex Desktop: automation_update omitted from tool manifest; visible heartbeat misses run and becomes daily

Open 💬 2 comments Opened Jul 12, 2026 by ohjonathan

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

26.707.41301 (build 5103)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Summary

The Scheduled Tasks UI is available in Codex Desktop, but the automation_update action is omitted from the callable-tool manifest supplied to a Codex task.

When I asked Codex to schedule a one-time continuation of the current task in two hours, the desktop instructions told the agent to use automation_update, but runtime inspection confirmed that no callable tool with that exact name was available.

An unsupported filesystem fallback created a heartbeat definition that the Scheduled UI discovered and displayed. However:

it did not execute at its first scheduled time;
it was displayed as a daily task even though the request was for a one-time follow-up;
after the missed time, the UI advanced to another daily occurrence;
no successful or failed scheduled-run record appeared in the target task.

The same general scheduling failure has occurred for me on three consecutive days.

Affected instance

Task ID: 019f547b-e2a7-7d11-b783-212b379a6ff3
Automation ID: falsification-review-of-company-os-pr-356
Requested at: July 12, 2026, approximately 12:13 AM PDT
Requested execution: July 12, 2026, 2:13 AM PDT
Confirmed missing at: approximately 8:00 AM PDT
Computer powered on: yes
ChatGPT desktop app running: yes

The Scheduled UI displayed:

Falsification review of company-os PR 356 Daily at 2:13 AM · Next run …

This is inconsistent with the requested one-time continuation and with the absence of any run in the target task.

What steps can reproduce the bug?

Open an existing local Codex task in the ChatGPT desktop app.

Ask Codex to schedule work that should return to the same task:

> Schedule a task to continue this existing task in two hours.

In the same task, ask Codex to perform this diagnostic without creating or modifying anything:

> Inspect your callable-tool registry for the exact tool name automation_update. Report whether it is present. Do not inspect the filesystem as a substitute.

Observe that the exact tool is absent. In the affected task, the equivalent runtime check returned false:

```js
ALL_TOOLS.some(tool => tool.name === "automation_update")

Separately, a manually written heartbeat definition under the local automation store is discovered by the Scheduled UI.

Observe that the one-time request is displayed as a daily schedule.

Keep the computer powered on and the ChatGPT desktop app running through the scheduled time.

Observe that no heartbeat turn is added to the target task and no successful or failed scheduled-run record is shown.

Observe that the Scheduled UI advances to the next daily occurrence.

The unsupported filesystem fallback is not proposed as a supported reproduction path. It demonstrates that the UI/storage layer can discover a schedule definition even while the task-facing action is unavailable and the scheduled execution does not occur.

What is the expected behavior?

The desktop host should expose automation_update in that task's callable-tool manifest.
Codex should create the heartbeat using the official action.
A request to continue once in two hours should not silently become an indefinite daily schedule.
The heartbeat should resume the target task at the requested time.
The Scheduled view should record either a successful run or a visible failure with diagnostic information.
If the action is unavailable, Codex should report that scheduling cannot be completed instead of allowing an unsupported fallback to appear successfully scheduled.

Additional information

RCA evidence

Confirmed

The Scheduled Tasks UI is enabled.
The installed desktop application contains an automation_update implementation and input schema.
The desktop instructions explicitly direct Codex to use automation_update for scheduling requests.
The affected task's actual callable-tool registry omitted automation_update.
The schedule definition was nevertheless visible in the Scheduled UI.
The requested execution produced no heartbeat turn in the target task.
The computer and desktop app were running at the scheduled time.
The UI displayed the one-time request as an active daily schedule with another future occurrence.

Likely failure boundary

There appears to be a mismatch among three desktop layers:

UI/storage layer: discovers and displays scheduled-task definitions;
tool-routing layer: does not expose automation_update to the Codex task;
execution layer: does not execute the visible heartbeat or record a failed run.

The accessible logs do not establish whether the underlying cause is capability gating, stale per-task capability registration, or a scheduler registration/execution defect.

Questions for maintainers

Why was automation_update omitted from the tool manifest while the Scheduled UI was enabled?
Is the callable-tool set pinned when a task is created, or refreshed for every turn?
Are filesystem-discovered automation definitions display-only until registered through the internal action?
Why is a schedule containing one-run intent displayed and advanced as a normal daily recurrence?
Why was no successful or failed run record produced?
Can the app warn when a schedule is visible but not executable?

Related issue

#16938 — Automation marked Active but does not run or create a thread

That report appears related to automation execution, but it concerns Windows and does not cover the automation_update tool-manifest omission observed here.

Documentation

OpenAI documents that scheduled work can be created from an existing Codex task and return to the same task context:

https://developers.openai.com/codex/app/automations#schedule-work-from-a-task

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗