Repository navigation
Codex Desktop inconsistently exposes automation_update across local threads #29128
Description
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.0build26A5353q - 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_updatevia targetedtool_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_searchreturned zero tools or unrelated connector tools, but notcodex_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.mdguidance.
Representative user-visible symptom:
- The agent says it cannot set a native heartbeat because
automation_updateis 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:
codex_app.automation_updateis consistently exposed in local Codex Desktop threads that are eligible to manage thread automations; or- 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
- Remote Control threads do not expose automation_update / automation tools while host Desktop can create heartbeats #26489 is related but Remote Control-specific. This report is about local Codex Desktop threads on the same machine/account.
- Codex Desktop: automation_update exposed in thread but rejected as non-local #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_updateexposure/tool injection.
Activity
github-actions commentedon Jun 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hanson-walker commentedon Jun 19, 2026
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 targetedtool_searchqueries. 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 commentedon Jul 1, 2026
Additional macOS/local recurrence with local-state evidence.
Environment:
Observed behavior:
codex_app.automation_update.automation_update, heartbeat, scheduled task, etc. returns unrelated plugin/connector tools, notcodex_app.Affected thread metadata:
originator:Codex Desktopsource:vscodethread_source:nullparent_thread_id:nullhas_dynamic_tools:falseImportant app-state difference:
thread-client-id-v1:local%3A<thread-id>entry in.codex-global-state.json.thread-client-id-v1:local%3A<control-thread-id> = client-new-thread:<uuid>.codex_app, includingautomation_update.App log signal:
ownerClientId=null.conversationId=client-new-thread:<uuid>withownerRoutePath=/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_appdynamic-tool injection.This is not explained by project trust/config, plugin install state, or general tool discovery failure.
yourprism commentedon Jul 22, 2026
Additional reproducible data point from macOS, same account and machine:
Current broken build
26.715.70719(build5650)codex-cli 0.145.0-alpha.27automation_updatetool first,” butautomation_updateis absent from the injectedcodex_appdynamic-tool manifest and fromALL_TOOLS. Targeted searches for automation/schedule/cron return no matching callable tool. The task therefore cannot create the scheduled task.Last known working control
26.715.521430.145.0-alpha.18codex_appmanifest contained 17 tools, includingautomation_update, and automation operations were callable.Manifest diff after the update
Removed:
automation_updatenavigate_to_codex_pageload_workspace_dependenciesuninstall_pluginAdded:
wait_threadsThe 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 commentedon Jul 27, 2026
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:
Codex Desktop0.145.0(current according to bothcodex doctorand npm)019fa42c-984c-7353-99e8-f754de9e76f3Observed:
automation_update.tool_searchcalls returned unrelated tools, nevercodex_app.automation_update.session_meta.dynamic_toolsmanifest contains the normal remote-capablecodex_appthread/project tools but omitsautomation_updateentirely.Local causes checked:
codex doctorreports the install consistent, app-server running, auth configured, and the installed version current.~/.codex/config.toml, and no localrequirements.tomldisables it.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_supporteddiagnostic and an actionable local-task handoff path.Related: #25873.
alessandrovarela commentedon Aug 24, 2026
Reproduction on Codex Desktop:
codex_app.automation_updatewas visible to the agent, but invoking it failed with: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 commentedon Aug 25, 2026
Additional local macOS recurrence with a version comparison that suggests a regression in the bundled Desktop runtime.
Environment:
Observed:
Version comparison on the same Mac/account:
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 commentedon Aug 25, 2026
Additional Windows ARM64 reproduction on the current Desktop release.
Environment:
26.818.8289.026.818.61809019f3421-934e-7471-8c1b-95c95f668565A read-only audit of the model-visible tool manifest in the affected Desktop task found:
codex_appsconnector toolsHowever, the following host tools were absent from the manifest:
automation_updatenavigate_to_codex_pageload_workspace_dependenciesuninstall_plugincreate_threadread_threadwait_threadstool_searchThis 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.