›_ Codex Issues
Codex Issues / #37556

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

Open 💬 2 comments Opened Aug 8, 2026 by MeGustas-5427
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 20 days ago

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

  • #36414
  • #36412

Powered by Codex Action

sankalp-phadnis · 10 days ago

I can reproduce this on macOS as well, and system sleep does not appear to be a necessary condition.

Environment

  • Codex desktop: 26.810.52044 (6662)
  • Bundled CLI: codex-cli 0.148.0-alpha.9
  • macOS 26.5.2 (25F84), Apple Silicon
  • Connected to AC power; pmset -g custom reported sleep 0
  • Codex disableSleep=1; the laptop remained awake throughout the failure and recovery

Reproduction (2026-08-18)

  1. A scheduled dispatcher run attempted to resolve its exact saved local Git project before creating any worktree tasks.
  2. The project-list call remained pending until the dispatcher's 30-second deadline.
  3. One fresh isolated retry also timed out after 30 seconds.
  4. Other activity in the same run—local filesystem work and GitHub/Linear API calls—continued normally.
  5. I then sent a normal foreground message to the existing Codex task (try now?). No project, authentication, network, power, or sleep setting was changed.
  6. The same exact project-list call returned in about 1.5 seconds.
  7. Two subsequent worktree-task creations, task listings, and pin operations all completed normally.

This has recurred on this Mac: project lookup also stalled on August 14, with earlier long task-list stalls on August 5 and 11.

Relevant sanitized log observation

During the failure window, the main renderer window was visible and often focused. Desktop logs showed repeated AppServerConnection reconnect attempts, approximately every 20 seconds, toward a saved remote-control environment that was offline (Remote environment is offline). That reconnect churn also appeared later when local project/thread calls were working, so I do not think the logs prove causality; it may simply be a useful correlation or contention clue.

Working RCA / expected behavior

The evidence points to an intermittent desktop project/task control-plane stall rather than macOS sleep. A foreground message appears to reactivate or refresh the route, after which the same operation succeeds immediately. An offline remote-host registration may be involved, but that remains unproven.

Expected: local project/thread management calls should remain responsive while the app is awake, regardless of an offline saved remote environment, and should fail with a bounded actionable error rather than remain pending.

I can provide a narrowly sanitized excerpt from the desktop log privately if useful; the full log contains account and host identifiers and should not be posted publicly.