Windows scheduled automation omits list_threads although codex_app reports ready

Environment

• Codex Desktop Windows package: 26.901.6511.0.
• Embedded CLI: 0.153.4.
• Local six-hour scheduled automation; same task later continued interactively.
• Observed on 7 September 2026.

Observed behaviour

The scheduled turn started normally. Its desktop log reported the codex_app server ready with no server-start error. During the turn, runtime inspection showed mcp__codex_app__list_threads absent from both the tool catalogue and callable tool object. The automation stopped without making task writes.

An interactive continuation of the same task later received the inventory tool. Two official inventory calls returned complete envelopes successfully. No app, provider, model, prompt or MCP configuration change was made between these observations.

Local reproduction of a possible mechanism

Read-only inspection of the installed desktop bundle found that automation startup derives a per-task mcp_servers.codex_app.enabled_tools filter from the renderer's dynamic-tool response. An empty response results in an archive-only tool list without a warning. A rejected request produces the same reduced list and logs a warning.

An offline test executed that exact extracted function against five synthetic inputs. Empty and rejected responses reproduced missing inventory; a complete namespace preserved inventory and task reading; deduplication and settings-write exclusion behaved as expected. The actual renderer response for the failed run is unavailable, so this does not establish whether a missing window, timeout, rejected request or another exposure/filtering failure was responsible.

Offline test results

These tests ran the exact function extracted read-only from the installed bundle. They reproduce a possible mechanism, not the actual failed-run renderer response:

The read-only canary subsequently completed two official inventory calls and one native task-history read. No claim is made that the next unattended start will receive the required tool.

Requested investigation and acceptance checks

Please investigate why a scheduled Windows turn can report the app server ready while required task tools are omitted. Avoid silently accepting an empty catalogue as an archive-only automation capability set. Verify that scheduled and interactive starts receive the permitted tool set, and test empty, delayed and rejected catalogue responses with a clear startup failure before operational work begins.

Related report: https://github.com/openai/codex/issues/33503. That report concerns desktop Run now on macOS; this observation concerns a scheduled Windows run. It should not be assumed to have the same trigger.

No source files or named tests are provided. Start at automation startup where mcp_servers.codex_app.enabled_tools is derived from the renderer's dynamic-tool response, then trace scheduled and interactive startup handling. Reproduce empty, delayed, and rejected catalogue responses; done means required tools are consistently exposed or startup fails clearly before operational work.