Desktop "Run now" creates automation tasks with a 1-tool manifest; scheduled and remote-initiated runs of the same automation receive the full codex_app tool suite

What version of the Codex App are you using?

ChatGPT Desktop 26.707.72221 on macOS 26.5.2 (Apple Silicon). Embedded codex-cli: 0.144.2.

What issue are you seeing?

An automation task created by clicking "Run now" in the desktop UI is stamped with a dynamic-tools manifest containing only set_thread_archived. The same automation, when fired by the scheduler or triggered remotely (phone via remote control), is stamped with the full 16-tool codex_app suite:

automation_update, create_thread, fork_thread, get_handoff_status, handoff_thread, list_projects, list_threads, load_workspace_dependencies, navigate_to_codex_page, read_thread, read_thread_terminal, send_message_to_thread, set_thread_archived, set_thread_pinned, set_thread_title, uninstall_plugin

The manifest is stamped once at task creation (visible in the rollout JSONL session_meta.tools) and is frozen for the life of the task. A run created through the desktop Run-now path therefore cannot call read_thread, list_threads, or any other thread tool, which breaks automation prompts that manage their own prior-run threads.

Evidence

Eight runs across two app sessions on 2026-07-15/16 (US Eastern), tool counts read from each rollout's session_meta.tools:

| Time (ET) | Automation | Trigger | rendererWindowFocused at creation | Tools stamped |
|---|---|---|---|---|
| 21:41 | trip planner | desktop Run now | true | 1 |
| 22:00 | trip planner | scheduler | n/a | 16 |
| 23:00 | trip planner | desktop Run now | true | 1 |
| 23:34 | one-time probe | scheduler (DTSTART) | n/a | 16 |
| 23:38 | trip planner | desktop Run now | true | 1 |
| 23:40 | trip planner | desktop Run now | true | 1 |
| 00:01 | stock watch | scheduler | false | 16 |
| 00:19 | trip planner | remote control (phone) | false | 16 |

Additional notes:

• App uptime is not a factor. The 23:38 and 23:40 desktop Run-now tasks were created 39 and 41 minutes after app start (22:59:33) and still received 1 tool. The 23:00 task was created 53 seconds after app start; same result. Only the creation path correlates.
• The desktop log shows the 00:19 run was preceded by remote_control_client_refresh_start_request / websocket enrollment lines, confirming the remote trigger. The 1-tool runs all show rendererWindowFocused=true on their first log lines; the 16-tool runs show false or fired from the scheduler.
• Every 1-tool run in the table is reproducible on demand: any desktop Run-now click on this machine produces a 1-tool task; every scheduler fire produces a 16-tool task.

What steps can reproduce the bug?

1. Create a recurring automation whose prompt inspects its available codex_app tools (for example, list ALL_TOOLS names in the exec harness and report them).
2. Let it fire on schedule once. The run reports the full 16-tool suite.
3. Click "Run now" on the same automation in the desktop UI.
4. The new run reports a single tool (set_thread_archived). read_thread, list_threads, and the rest are absent, and they never appear later within that task.
5. Trigger the same automation remotely (phone remote control). The run again reports the full suite.

What is the expected behavior?

Run-now tasks receive the same dynamic-tools manifest as scheduler-fired tasks for the same automation. At minimum, the manifest for a given automation should not depend on which UI surface created the task.

What do you see instead?

Desktop Run-now tasks are limited to set_thread_archived for their entire life. Automation prompts that read or archive their prior run threads fail their tool gate on every manual run, while behaving correctly on every scheduled run, which makes manual testing of automations misleading.

Possibly related existing issues

• #24019, #26954, #22007: other defects specific to the Run-now creation path (blank or empty sessions). This report is a different symptom on what looks like the same path: the task is created and executes, but with a minimal tool manifest.
• #28080: intermittent loss of thread-tool handlers mid-session. Different failure (handlers lost later); this report is about the manifest stamped at creation. We have also observed one hang of a list_threads call in a full-suite scheduled run on this machine, which matches #28080 more closely.
• #29223, #30233: sessions missing codex_app thread tools in other contexts (version regression, interactive tool search). Neither covers the Run-now vs scheduler differential.