automation_update unavailable in one Windows chat despite working in another

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

• #22852

Powered by Codex Action

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.

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?

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.

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.

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.

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.

i dont understand why openai is shipping and doing all these releases without any testing. i mean this is core functionality of tool usage and it doesnt work. looks like they are just vibe coding the codex itself with no one reviewing the architecture or implementation. if it works out-of-box lets just ship it. and then all these headlines about how the latest models can do anything. if you have access to latest models and unlimited token usage how come the core functionality doesnt work.

Additional Windows repro from another Codex Desktop session.

Environment:

• OS: Windows
• Codex app: updated
• App was restarted multiple times
• The issue reproduces across multiple separate threads, not only one stale thread

Observed:

• Asking the assistant to discover automation_update returns 0 matching tools.
• Other app/plugin tools are still discoverable and callable, so this appears scoped to automation tool exposure rather than global tool discovery.
• Local automations do exist under %USERPROFILE%\.codex\automations.
• The assistant can read automation definitions directly from filesystem. Example automation.toml fields are present: kind = "cron", status = "ACTIVE", rrule, prompt, model, reasoning_effort, execution_environment, cwds.
• This means automations are present locally, but the intended app-level automation-management tool is not exposed to the thread.

Impact:

• Users can create/manage automations in a separate UI section, but the assistant in the current thread cannot inspect/update them through the documented tool path.
• Filesystem inspection is possible as a workaround, but it is not equivalent to automation_update because it bypasses app-level validation, thread attachment, and tool-owned update semantics.

This looks like a session/tool-manifest exposure bug or account/workspace feature-flag inconsistency, not a missing local automation directory.