Codex Desktop inconsistently exposes automation_update across local threads

Summary

codex_app.automation_update is inconsistently exposed across Codex Desktop threads on the same Mac, account, workspace, and network.

In one local Desktop thread, targeted tool_search exposes codex_app.automation_update and native heartbeat create/update operations succeed. In several other local Desktop threads from the same machine/account, the same targeted discovery queries for automation_update, heartbeat, and thread wakeup return zero or unrelated tools, so the agent cannot create or update native thread wakeups.

This is distinct from cases where automation_update is visible but rejected as non-local. Here, the tool is sometimes absent from the model/tool surface entirely after targeted discovery.

Environment

• Product surface: Codex Desktop
• Codex app: 26.616.32156
• Codex CLI/runtime: codex-cli 0.142.0-alpha.1
• OS: macOS 27.0 build 26A5353q
• Same user account, device, workspace area, and network across working and failing examples
• Support case with direct screenshot/screen recordings already opened: OpenAI Support case 09882314

Observed behavior

Working/control thread:

• A thread dedicated to heartbeat/wakeup coordination can lazy-load codex_app.automation_update via targeted tool_search.
• In that thread, native heartbeat create/update calls have succeeded repeatedly.

Affected local Desktop threads:

• Agents followed the same discovery pattern and searched for automation_update, heartbeat, thread wakeup, and related terms.
• tool_search returned zero tools or unrelated connector tools, but not codex_app.automation_update.
• Other lazy-loaded capabilities can still appear in those sessions, so this is not simply "all dynamic tools missing."
• The affected threads receive local agent instructions correctly, so this is not explained by missing AGENTS.md guidance.

Representative user-visible symptom:

• The agent says it cannot set a native heartbeat because automation_update is not exposed in that session.
• The same user can switch to another local Codex Desktop thread and create/update a heartbeat for the target thread from there.

Why this matters

Thread wakeups/heartbeats are a native Codex Desktop workflow. When automation_update is inconsistently exposed, agents cannot reliably schedule follow-ups, reminders, or monitoring checks from the thread where the work is happening.

The practical failure mode is confusing:

• Some threads can set native heartbeats.
• Some threads cannot discover the tool at all.
• The user sees a clock icon in one thread but not another.
• Agents may attempt local fallback files or handoffs unless given custom guardrails.

Expected behavior

One of these should be true:

1. codex_app.automation_update is consistently exposed in local Codex Desktop threads that are eligible to manage thread automations; or
2. the tool discovery/runtime provides a diagnostic explaining why the current thread is not eligible, including whether the blocker is thread origin, dynamic tool injection, workspace classification, target thread state, account/workspace permissions, or app runtime state.

At minimum, tool_search should not silently omit the native automation tool in one local Desktop thread while exposing it in another comparable local Desktop thread.

Related issues

• #26489 is related but Remote Control-specific. This report is about local Codex Desktop threads on the same machine/account.
• #25873 is related but distinct: there the tool is exposed and then rejected as non-local. Here, the tool is sometimes not exposed at all after targeted discovery.
• Other heartbeat/automation issues show the broader automation surface is fragile, but this report is specifically about inconsistent automation_update exposure/tool injection.