automation_update unavailable in one Windows chat despite working in another

[spclkr]

Summary

Codex Desktop on Windows appears to expose automation-management tools inconsistently across chats. One chat was able to create a recurring automation successfully, while another chat in the same app/session could not discover or call automation_update at all.

Observed Behavior

In one chat, Codex created a weekly automation successfully:

• Name: Energy Complex Weekly
• Automation ID: energy-complex-weekly
• Schedule: Saturdays at 8:00 AM local time
• Recipient: configured Gmail recipient
• Subject format: Energy Complex Weekly - YYYY-MM-DD

In a different chat, when asked to inspect/update/create automation behavior:

• The assistant searched for automation_update directly via tool discovery.
• Tool discovery returned 0 matching tools.
• The assistant could not use the app-level automation-management tool.
• The automation did exist locally under the user's Codex automations directory.
• The assistant could inspect/edit the local automation definition through filesystem access, but not through the intended automation tool.

Expected Behavior

When the user asks to create, inspect, or update automations, automation_update should be consistently exposed, or Codex Desktop should clearly explain why that tool is unavailable in the current chat context.

At minimum, tool exposure should not differ silently between two chats where both are being used for automation-related work.

Why This Matters

The inconsistency makes automation management confusing. In one chat, the user can create an automation normally. In another, the assistant says the automation tool is unavailable, even though an automation exists and can be modified indirectly through local files.

This is especially noticeable on Windows, where the local automation files are visible but the app-level tool discovery does not appear deterministic across chats/surfaces.

Environment

• Product: Codex Desktop
• OS: Windows
• Automation ID involved: energy-complex-weekly
• Date observed: 2026-05-17

Reproduction Sketch

1. In one Codex Desktop chat, ask Codex to create a recurring automation.
2. Confirm the automation is created successfully.
3. In another Codex Desktop chat, ask Codex to create/update/check an automation.
4. Have the assistant search for automation_update.
5. Observe that tool discovery returns 0 results, even though another chat was able to use automation functionality.

Notes

The same session still had other plugin tools available, including GitHub, Gmail, Slack, Calendar, Linear, and local filesystem tools. The issue appears specific to the app-level automation-management tool exposure rather than all tool discovery.

[github-actions]

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

• In-app Browser enabled but browser automation tool unavailable in mobile-created Codex thread #22852

Powered by Codex Action

[spclkr]

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

• In-app Browser enabled but browser automation tool unavailable in mobile-created Codex thread #22852

Powered by Codex Action

I don't think the issue I reported is a duplicate. The issue is reported is inconsistent behavior in the same Codex Desktop App. I can access the automation_update tool calling in one thread but not in another one.

[etraut-openai]

Can you think of any differences between the two threads? Is one of them much older? Was it started from the CLI or IDE extension rather than the app? Is it a subagent thread?

[spclkr]

Nope not much different. One is a week old and the other a new one. Both were created in the same Desktop App, no CLI usage. And they both are in the same project just different chat threads. Only thing I can think of is that I updated the Codex App to the latest as I always do whenever there is a down arrow.

[etraut-openai]

Is the older one (from a week ago) the one where it's not working? If so, that might explain the problem. Let us know if you see a similar problem for threads created with the latest version of the app.

[spclkr]

Actually its the other way around. The older chat thread which was created with older version still can access it but not the new chat thread that I used today after the update. In fact I can still reproduce as we speak.

[salomon1111]

I am seeing the same class of issue in Codex Desktop on Windows, but with the opposite old/new chat direction.

In my case:

• Same Codex Desktop installation
• Same Windows machine
• Same project/workspace
• A new chat in the same project can create and execute an automation successfully
• This existing thread cannot access codex_app.automation_update
• Repeated tool_search attempts for automation_update only expose other connector tools, not the automation-management tool
• Local automation files exist under C:\Users\user\.codex\automations, so the automation feature itself works

This suggests the problem is not tied specifically to new chats or old chats. It looks like per-thread tool exposure for codex_app.automation_update can become inconsistent.

......
Additional data point: I can also create a new automation manually through the Codex Desktop UI via Automations -> New automation. That works without issue. The failure is specifically that this particular chat does not expose codex_app.automation_update to the assistant, even though the app-level automation UI and scheduler work.

.....
Additional confirmation from my side:

I just tested this again in a brand new thread in the same project and asked the agent to create a test automation. That worked successfully.

So in my case the split is now very clear:

• same Codex Desktop installation
• same machine
• same project
• same user
• manual automation creation through the Automations UI works
• agent-based automation creation in a new thread works
• only this specific thread does not expose codex_app.automation_update

This makes it look even more like a thread-local session/tool-mounting bug rather than a general automation failure.