Codex Desktop: automation_update exposed in thread but rejected as non-local

Summary

automation_update can be exposed in a Codex Desktop thread's model tool surface, but calls to it can still fail with:

Automations are only supported for local threads.

This makes it unclear whether the thread is actually automation-capable. The tool appears available to the agent, but the app runtime rejects the operation.

Environment

• Product surface: Codex Desktop
• OS: macOS 26.5 (25F71)
• Codex CLI/runtime: codex-cli 0.136.0-alpha.2
• Thread cwd: /Users/joshmcculloch/Documents/Codex
• Thread metadata from local state DB: thread_source = user

Observed behavior

In the affected thread:

• automation_update is exposed in the model tool surface.
• A mode: view call against an existing automation id returns:

Automations are only supported for local threads.

Local thread metadata does not make the reason obvious:

• The thread is in a local workspace path.
• The thread source is user.
• The thread was expected to be usable from a Mac Mini/Codex Desktop local workflow, even though it may be controlled from another Mac through remote control.

This differs from cases where automation_update is simply absent. Here, the model-visible tool exists, but the runtime rejects the action.

Why this is hard to diagnose

The current surfaces appear to conflate two different states:

1. automation_update is present in the model/tool surface.
2. The current app runtime will actually accept an automation operation for this thread.

When those disagree, the agent cannot reliably tell whether the blocker is:

• thread origin;
• remote-control origin;
• local-vs-remote workspace classification;
• thread_source;
• cwd/project path;
• existing target thread state;
• or app runtime state.

Impact

This affects long-running command-centre / coordination threads that need to update or verify existing heartbeat automations. The user may believe a thread is automation-capable because automation_update is exposed, while the operation is rejected at runtime.

Expected behavior

One of these should be true:

• automation_update is only exposed when the current thread/runtime can actually use it; or
• automation_update provides a diagnostic explaining why the thread is considered non-local and what needs to change.

Helpful diagnostics would include:

• whether the thread is considered local or remote by the automation subsystem;
• which field caused that classification;
• whether a remote-control-created or remote-control-operated Mac Mini thread can update local automations;
• whether the operation failed because of thread origin, cwd, target thread, app-runtime state, or permissions.

Related but distinct issues

This seems related to general Codex Desktop automation/thread lifecycle instability, but it is distinct from automation runs being auto-archived or not started. The key symptom here is: automation_update is visible to the model, but rejected by the app/runtime as non-local.