[App][Scheduled Tasks] Thread-management calls hang until a foreground message is sent #37556

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.41515 (6321)

What subscription do you have?

Pro 20X

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

A background Scheduled Task can complete its local file, browser, network, and validation work, but its thread-management calls (list_projects, list_threads, and create_thread) can remain pending without returning a result or an explicit error.

After I send a fresh foreground user message through either the desktop or mobile client, retrying the same calls with the same validated input succeeds. No project, input, authentication, or application configuration is changed between the failed background attempt and the successful foreground retry.

The behavior is intermittent but recurring and prevents the workflow from completing unattended.

What steps can reproduce the bug?

1. Configure a Codex Scheduled Task that operates on a saved local project.
2. Keep the computer powered on, the Codex App running, and the project available.
3. Let the Scheduled Task complete its normal local, browser, network, and validation operations unattended.
4. Have the task call list_projects to resolve the saved project and then call create_thread.
5. Observe that these calls may remain pending without returning a result or an explicit error. A subsequent list_threads call may also remain pending.
6. Do not submit another creation request because the original creation status is unknown.
7. Send a fresh foreground user message through the desktop or mobile client.
8. Recheck for duplicate tasks and retry the same thread-management calls using the same validated input.
9. Observe that list_threads, list_projects, and create_thread now return normally and the follow-up task is created successfully.

What is the expected behavior?

Background Scheduled Tasks should be able to call list_projects, list_threads, and create_thread without requiring a foreground user message.

Each operation should return either a successful result or an explicit error or timeout. The outcome of create_thread should be deterministic so that an unattended workflow can safely avoid duplicate creation requests.

Additional information

No visible error message is returned; the affected calls remain pending.

The same Scheduled Task successfully completes its other local, browser, network, and validation operations before the thread-management failure. The project remains available, and no configuration or authentication change is made before the successful retry.

A foreground user message may be refreshing or reactivating a background session, project route, host route, or authorization context. This is only a hypothesis based on the observed behavior.

I can provide sanitized diagnostic information privately if required. Sensitive paths, customer data, credentials, raw logs, and internal identifiers have intentionally been omitted from this public report.