Desktop exposes automation_update without a handler, leaving automations unmanageable

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.