[macOS][Automations] Scheduled local run stalls until the thread is opened and resumed #35950

Summary

A project-scoped scheduled local automation creates its thread at the expected time and starts a small amount of reasoning, but then stops making progress before its first tool call. No approval is pending. The run resumes automatically, without restarting the app, only after I enter the desktop session and open the affected thread.

This reproduced on two consecutive days and across two desktop app builds.

Expected behavior

A scheduled task should run unattended in the background while the Mac is powered on, the desktop app is running, and the selected local project remains available.

Actual behavior

The task appears as running, but its stream has no owner (streamRole=null). Opening the scheduled thread causes the desktop client to call thread/resume; the stream then becomes role=owner, and the first tool call proceeds immediately.

This makes the task look active even though no project tool or shell work is taking place.

Reproduction

1. Configure a project-scoped scheduled automation with a local execution target on macOS.
2. Leave the Mac powered on with the desktop app running and the local project available.
3. Do not interact with or open the scheduled thread when the schedule fires.
4. Observe that the automation thread is created and emits a few initial reasoning events, but does not invoke its first tool.
5. Enter the desktop session and open the affected scheduled thread.
6. Observe that the client sends thread/resume, assigns the stream owner, and the automation continues without an app restart or manual rerun.

Evidence

Run 1

• Thread: 019fa89a-2a57-78f0-9945-748440867df1
• Created: 2026-07-28 20:01:43 Asia/Shanghai
• Last initial reasoning event: 20:02:05
• thread/resume: 23:28:07
• First tool result: 23:28:19
• Delay: approximately 3h26m
• Desktop build recorded by the run: 26.721.41059

Run 2

• Thread: 019fadbe-ffe2-72a0-b64d-59cdf6dae4b7
• Created: 2026-07-29 20:00:03 Asia/Shanghai
• Last initial reasoning event: 20:00:33
• thread/resume: 20:16:36
• First tool result: 20:16:45
• Delay: approximately 16m42s
• Desktop build: 26.721.81911 (build 5973)

For both runs:

• The Mac did not sleep during the stalled interval.
• The desktop app remained alive and continued successful periodic configuration/network refreshes.
• No first-step tool call was issued before the UI-driven resume.
• The sequence in the desktop logs is streamRole=null → thread/resume → role=owner → first tool result.
• No app restart or manual rerun occurred.

A fresh codex doctor --summary --no-color run outside the task sandbox reports:

• state databases healthy
• rollout files and state DB thread inventory agree
• WebSocket connected (HTTP 101 Switching Protocols)
• active provider endpoints reachable over HTTP

Environment

• ChatGPT desktop app / Codex surface: 26.721.81911, build 5973
• Bundled codex-cli: 0.146.0-alpha.3.1
• macOS: 26.5.2, arm64
• Execution target: local project
• Automation ID: a
• Schedule: weekday evening, Asia/Shanghai

Related issues

Possibly related, but not identical because those reports are Windows-specific and describe a different start/resume path:

• Windows Codex Desktop creates automation thread but never starts agent turn #19011
• Codex Desktop scheduled automations create empty sessions with no prompt or task turn #19969

Privacy / logs

Raw desktop logs and the full automation session are intentionally not attached because the saved automation prompt contains private local delivery configuration. Sanitized timestamps, thread IDs, state transitions, and diagnostic results are included above. Additional sanitized log excerpts can be provided if needed.