›_ Codex Issues
Codex Issues / #29128

Codex Desktop inconsistently exposes automation_update across local threads

Open 💬 8 comments Opened Jun 19, 2026 by hanson-walker
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28650

Powered by Codex Action

hanson-walker · 2 months ago

I reviewed #28650. I do not think this is an exact duplicate.

#28650 asks for an automation tool to be exposed in Codex App sessions generally. This issue is narrower/different: on the same local Codex Desktop install/account, one thread can discover and use codex_app.automation_update, while other comparable local Desktop threads cannot discover it after the same targeted tool_search queries. So the problem here is inconsistent dynamic tool exposure across local threads, not simply that the app lacks an automation API everywhere.

If maintainers prefer to consolidate under #28650, the key detail to carry over is the working/control-vs-failing-thread comparison on the same machine/account.

klungg · 1 month ago

Additional macOS/local recurrence with local-state evidence.

Environment:

  • Codex Desktop release observed in logs: 26.623.70822
  • CLI/runtime: 0.142.4
  • Platform: macOS / Darwin
  • Affected thread was created from the normal Codex Desktop UI in a local project workspace.

Observed behavior:

  • The affected thread cannot discover or call codex_app.automation_update.
  • Targeted discovery for automation_update, heartbeat, scheduled task, etc. returns unrelated plugin/connector tools, not codex_app.
  • Other tools/plugin discovery still works, so this appears scoped to app dynamic-tool exposure rather than all tool discovery.

Affected thread metadata:

  • originator: Codex Desktop
  • source: vscode
  • thread_source: null
  • parent_thread_id: null
  • has_dynamic_tools: false

Important app-state difference:

  • The affected thread has no thread-client-id-v1:local%3A<thread-id> entry in .codex-global-state.json.
  • A working/control thread on the same machine does have thread-client-id-v1:local%3A<control-thread-id> = client-new-thread:<uuid>.
  • That working/control thread receives codex_app, including automation_update.

App log signal:

  • Affected thread shows ownerClientId=null.
  • The working/control thread routes through conversationId=client-new-thread:<uuid> with ownerRoutePath=/local/<thread-id>.

Interpretation:
This looks like a thread-local app dynamic-tool provisioning/state bug. The affected thread exists normally in history, has title/cwd/messages, and appears in the UI, but it was not given the app client/thread binding that appears to accompany codex_app dynamic-tool injection.

This is not explained by project trust/config, plugin install state, or general tool discovery failure.

yourprism · 1 month ago

Additional reproducible data point from macOS, same account and machine:

Current broken build

  • ChatGPT/Codex Desktop: 26.715.70719 (build 5650)
  • Embedded runtime: codex-cli 0.145.0-alpha.27
  • Trigger path: open Scheduled in the desktop sidebar and start creating a scheduled task from chat
  • Result: the fresh task receives the automation-specific app instructions, including “search for the automation_update tool first,” but automation_update is absent from the injected codex_app dynamic-tool manifest and from ALL_TOOLS. Targeted searches for automation/schedule/cron return no matching callable tool. The task therefore cannot create the scheduled task.

Last known working control

  • Desktop: 26.715.52143
  • Embedded runtime: 0.145.0-alpha.18
  • Observed 2026-07-20 on the same Mac/account
  • The injected codex_app manifest contained 17 tools, including automation_update, and automation operations were callable.

Manifest diff after the update
Removed:

  • automation_update
  • navigate_to_codex_page
  • load_workspace_dependencies
  • uninstall_plugin

Added:

  • wait_threads

The current build still injects the other thread-management tools, so this is not a general sandbox, repository-trust, or account-access failure. Full-access mode is active. Fully fresh tasks reproduce the omission.

The user-facing inconsistency is particularly sharp: the Scheduled-sidebar flow and desktop instructions explicitly tell the agent to create/manage the automation, but the client-provided tool manifest omits the only supported automation mutation tool. No private session IDs, prompts, credentials, or filesystem paths are included here.

amadad · 1 month ago

Correction / scope clarification: this reproduction comes from a Codex Desktop task backed by a remote SSH Linux project, not a local Desktop project. Existing reports such as #25873 show that the automation subsystem currently treats non-local threads as ineligible (Automations are only supported for local threads). Therefore this should not be treated as independent evidence of the local-thread inconsistency reported in this issue.

It is still useful evidence of a related diagnostic gap on current stable runtime:

  • Originator recorded in rollout metadata: Codex Desktop
  • Backing host: remote SSH Linux project
  • Codex CLI/app-server: 0.145.0 (current according to both codex doctor and npm)
  • Task ID: 019fa42c-984c-7353-99e8-f754de9e76f3
  • Date: 2026-07-27

Observed:

  1. The remote-backed task was asked to migrate 11 existing automations into Codex Scheduled Tasks.
  2. Desktop instructions explicitly told the agent to search for automation_update.
  3. Multiple targeted tool_search calls returned unrelated tools, never codex_app.automation_update.
  4. The initial session_meta.dynamic_tools manifest contains the normal remote-capable codex_app thread/project tools but omits automation_update entirely.
  5. No structured eligibility reason is surfaced to the agent; the only indication is silent tool omission.

Local causes checked:

  • codex doctor reports the install consistent, app-server running, auth configured, and the installed version current.
  • No automation/scheduling override exists in ~/.codex/config.toml, and no local requirements.toml disables it.
  • No unsupported filesystem fallback was attempted; the source automations were left unchanged.

Revised interpretation:

This is most likely the current remote-host limitation, not a local capability regression. The remaining product problem is discoverability: Desktop instructions advertise automation management generically, while remote-backed tasks silently omit the tool instead of returning a structured remote_threads_not_supported diagnostic and an actionable local-task handoff path.

Related: #25873.

alessandrovarela · 3 days ago

Reproduction on Codex Desktop: codex_app.automation_update was visible to the agent, but invoking it failed with:

No handler registered for tool: codex_app.automation_update

No eligibility, permission, target-thread, or sandbox diagnostic was returned, and no automation was created.

This differs from discovery omission: the tool contract is visible while its execution handler is absent. Both cases prevent reliable same-thread continuation for long-running workflows.

Please make tool exposure and backend registration atomic, or return a structured diagnostic and explicit confirmation that the automation was created.

wraiser · 2 days ago

Additional local macOS recurrence with a version comparison that suggests a regression in the bundled Desktop runtime.

Environment:

  • Codex Desktop: 26.818.61809 (build 7019)
  • Bundled Codex CLI: 0.149.0-alpha.4.3
  • macOS: 27.0
  • Observed: 2026-08-25

Observed:

  • Existing scheduled automation configuration remains valid, readable, active, and unchanged.
  • Newly created local Desktop threads do not expose automation_update in the live tool list.
  • In a thread where the tool contract was callable, invocation returned: No handler registered for tool: automation_update
  • Restarting the Desktop app and its app-server did not restore the handler.

Version comparison on the same Mac/account:

  • Bundled CLI 0.149.0-alpha.4.1: automation_update was exposed in 3 of 4 checked sessions.
  • Bundled CLI 0.149.0-alpha.4.3: automation_update was exposed in 0 of 3 checked sessions.
  • The PATH CLI is 0.149.1, but the Desktop process uses its bundled 0.149.0-alpha.4.3 binary, so updating the PATH CLI does not affect the failing surface.

Pre-update Desktop logs contained dynamic_app_tool_server_request_received and dynamic_app_tool_renderer_execution_started events for automation_update. Current-process logs and fresh sessions contain no automation_update registration.

Expected: tool exposure and handler registration should be atomic, or the client should return a structured eligibility/registration diagnostic. No automation settings or files were modified. Feedback was also recorded through Codex without uploading logs or session data.

nos1609 · 2 days ago

Additional Windows ARM64 reproduction on the current Desktop release.

Environment:

  • Microsoft Store package: 26.818.8289.0
  • Desktop release reported by the active client: 26.818.61809
  • Correlation task ID: 019f3421-934e-7471-8c1b-95c95f668565

A read-only audit of the model-visible tool manifest in the affected Desktop task found:

  • 537 tools total
  • 518 MCP-prefixed tools
  • 489 codex_apps connector tools
  • GitHub connector tools remained callable and completed successfully

However, the following host tools were absent from the manifest:

  • automation_update
  • navigate_to_codex_page
  • load_workspace_dependencies
  • uninstall_plugin
  • create_thread
  • read_thread
  • wait_threads
  • any callable tool_search

This is not a total MCP outage. It is selective omission of Codex host tools while generic connector tools remain available. The task still receives Desktop instructions that explicitly require some of the omitted tools, so the agent cannot follow those instructions and may appear to have forgotten how to use tools.

Expected behavior: Desktop instructions, dynamic tool contracts, and registered handlers should be provisioned atomically. If a task is ineligible, expose a structured reason instead of silently omitting the tools.

Privacy: no account data, local paths, hostnames, repository names, prompts, or logs are included.