›_ Codex Issues
Codex Issues / #32294

Desktop exposes automation_update without a handler, leaving automations unmanageable

Open 💬 4 comments Opened Jul 11, 2026 by ttrias
💡 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?

Codex Desktop on macOS (current installed build; exact bundle version was not available to the tool session).

What platform is your computer?

macOS, Apple Silicon.

What issue are you seeing?

The Desktop tool catalog exposes codex_app.automation_update, but invoking it fails with:

No handler registered for tool: codex_app.automation_update

The failure is repeatable within the same active thread.

This is more than a failed create operation. Because automation changes are required to go through automation_update, the missing handler leaves no supported way to manage automation state associated with the thread.

Operational consequences include:

  • Cannot create a requested five-minute heartbeat automation.
  • Cannot pause or resume an existing automation.
  • Cannot change its interval.
  • Cannot delete it.
  • Cannot reliably inspect or repair its thread association.
  • A shell fallback such as gh pr checks --watch cannot wake the conversation when it exits, so the user must manually send another message.
  • Directly writing an automation TOML file is not a supported fallback and cannot be safely verified through the app.

The most frustrating case is an automation that already exists: the thread can be aware that automation management should be available while being unable to pause, modify, or remove the automation.

What steps can reproduce the bug?

  1. Open a local project thread in Codex Desktop.
  2. Ask Codex to create or update a heartbeat automation.
  3. Observe that codex_app.automation_update is present in the exposed tool catalog.
  4. Invoke it with a valid heartbeat create/update payload.
  5. Observe:
No handler registered for tool: codex_app.automation_update
  1. Retry the call and observe the same result.
  2. Attempt to use a supported fallback to manage an existing automation; none is exposed.

What is the expected behavior?

  • If codex_app.automation_update is exposed, its Desktop-side handler should be registered and callable.
  • If the handler is unavailable, the tool should not be advertised as callable.
  • Desktop should provide a structured recovery path, such as reinitializing the handler or exposing a supported automation-management fallback.
  • Existing automations must remain viewable, pausable, editable, and deletable even when one tool bridge fails.
  • Background watches should have a supported way to notify or resume the owning thread on completion.

Additional information

Related: #28080 reports other Desktop thread tools intermittently losing handlers. This report focuses specifically on automation management and the absence of any supported recovery path, which can strand already-configured automation state.

Observed on 2026-07-10. No credentials or repository data are required to reproduce.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30905
  • #31119

Powered by Codex Action

ttrias · 1 month ago

Additional environment and workaround evidence:

  • The Codex app build recorded in ~/.codex/config.toml is 26.707.31428.
  • Reading ~/.codex/automations/*/automation.toml confirms that automation state remains present on disk. In this case, the relevant review-cycle heartbeat is PAUSED, runs on a five-minute rule, and retains a target_thread_id.
  • We can potentially write our own local tools to read and modify these TOML files. That provides a possible emergency workaround, but it would require users to bypass the app's supported automation handler and independently reproduce its validation, timestamping, lifecycle, thread-association, and persistence semantics.
  • A custom file-management workaround also cannot confirm that Desktop has reloaded or reconciled the edited state correctly.

The on-disk files make the missing handler especially confusing: the state exists and is inspectable, but the supported tool needed to safely manage it is unavailable. Custom tooling may mitigate the immediate problem, but it should not be the required management path.

ttrias · 1 month ago

Additional evidence suggests this may be sensitive to how a turn reaches the Desktop host:

  • The failing automation request at 2026-07-10 23:36 UTC had no client_id on its recorded user_message.
  • Two automation_update calls then failed with No handler registered.
  • The later successful request at 2026-07-11 00:31 UTC had a Desktop-style client_id.
  • At 00:32 UTC, the same thread successfully called automation_update in read-only view mode without changing the automation TOML or restarting the thread.

This correlates with, but does not conclusively prove, a difference between a relayed/Remote-originated turn and a turn sent directly through Desktop.

The documented Remote model says the connected host supplies the task's local tools, configuration, permissions, and plugins, while the phone sends prompts and approvals. Therefore, even if the failing request arrived through Remote, losing the Desktop automation handler is not expected behavior.

Relationship to #28080:

  • #28080 reports multiple Desktop thread-management tools becoming advertised but uncallable after their handlers disappear.
  • This issue reports the same apparent discovery/handler-registry divergence for automation_update.
  • The automation case has additional persistence impact: automation state remains on disk, but users cannot safely pause, edit, delete, or reconcile it through the supported API.
  • In both cases, the likely shared invariant is that Desktop must not expose a tool unless its handler is registered, and registered handlers should survive or be restored across turns and remote-control transitions.

Official documentation covers Scheduled management and Remote host behavior, but does not document dynamic handler registration, this error, source-dependent capability differences, or a recovery procedure.

ESKehler · 16 days ago

Related but distinct reproduction: one active Codex task omitted the native automation_update capability from its live tool registry entirely, while another active task on the same connected host exposed it normally.

The user asked the affected task to set a heartbeat. Because automation_update was not callable, the task could not create a native heartbeat and fell back to a hidden local monitor process. That fallback cannot provide the same supported task wake/resume behavior.

This differs from the original #32294 symptom: the tool was not advertised and then rejected by a missing handler; it was absent from the registry from the outset. It is also related to the reduced capability-profile behavior in #34526, but demonstrates that automation/heartbeat capabilities can be affected, not only task-management tools.

Expected behavior: supported automation capabilities should be injected consistently across tasks and control/resume surfaces. If heartbeats are intentionally unavailable for a task profile, the product should expose that limitation explicitly rather than encouraging an agent to invent a local-process substitute.