›_ Codex Issues
Codex Issues / #31584

Codex automation stalls indefinitely on app tool call until generated thread is opened manually

Open 💬 3 comments Opened Jul 8, 2026 by zdaman101

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

Version 26.623.141536

What subscription do you have?

Codex PRO $200 level

What platform is your computer?

macOS: Darwin 25.5.0 arm64 arm

What issue are you seeing?

A scheduled Codex automation started at the expected time and received its automation prompt, but it did not continue executing for roughly 6.5 hours. It only resumed after I manually opened the automation thread in the Codex desktop app.

Local evidence shows the automation session did start and began work, but then blocked on a Codex app tool call:

  • Session ID: 019f40a3-1c01-7542-9ca9-533f1faab73d
  • Automation ID: pr-review
  • Codex app / CLI version in rollout: 0.142.5
  • Automation thread source: automation
  • Blocked tool: codex_app.list_projects
  • Tool call ID: call_BUFwI7nKqgz60LqMd3yojRK9
  • Tool call started: 2026-07-08T07:31:29.134Z
  • Tool call returned: 2026-07-08T13:51:47.118Z

After the delayed list_projects response returned(which only occurred after I manually opened the thread ~6.5 hours later), the automation immediately continued, created the requested review thread, and proceeded normally. This makes the automation unreliable for unattended work because it appears to require manual UI activation to unstick.

What steps can reproduce the bug?

Feedback ID: 019f420c-c523-71b3-a85b-ecacb965037c

What is the expected behavior?

A scheduled automation should continue executing in the background after the automation prompt is delivered, without requiring the user to open the generated thread in the Codex app.
If an app-side tool call such as list_projects cannot complete, the automation should fail visibly, time out, retry, or report an actionable error in the automation/Triage UI. It should not sit blocked for hours and then resume only after manual thread activation.

Additional information

GitHub would not let me enter more info into the "What steps can reproduce the bug" section outside of my Feedback ID so I am entering that information below:

  1. In Codex desktop, create a standalone project-scoped cron automation against a local Git project.
  2. Use a prompt that asks the automation to create a background Codex thread/worktree, then poll it. Example shape:

```Assist me with code review for PR #778.

Goal: iterate until two consecutive code reviews do not surface any P0-P2 issues.

Steps:

  1. Open a new thread and ask for a thorough code review of the PR branch compared to local main.
  2. Poll every 60 seconds until the review is complete.
  3. Fix agreed P0-P2 issues and commit changes locally.
  4. Archive the review thread.

3. Let the automation run on schedule without opening its generated automation thread.
4. Observe that the automation thread is created and receives the prompt, but execution stalls.
5. Open the automation thread manually in Codex desktop.
6. Observe that the automation resumes and continues from the original prompt without any additional user instruction.

View original on GitHub ↗

3 Comments

jtcchan · 1 month ago

Additional evidence from Codex Desktop 26.707.72221 (build 5307) on macOS, including a later recovery signal.

Observed behavior:

  • A list_projects call remained unresolved for about 72 seconds before the run was terminated.
  • A subsequent set_thread_title call remained unresolved for about 65 seconds before termination.
  • During those stalls, Desktop logged the primary renderer as visible but focused=false; there was no corresponding "Sending server response" entry and no structured tool error.
  • In the same app runtime, native task-tool calls from a healthy persistent task later completed in milliseconds while the renderer was focused=true.
  • The user has now retried previously blocked tasks and they run. That makes this look like a transient activation/turn/renderer-state failure rather than a permanently dead app-server.

Read-only inspection of the packaged Desktop code provides a plausible mechanism:

  • These task tools are Desktop-hosted dynamic tools, not ordinary plugin MCP tools.
  • The renderer's dynamic-tool dispatcher awaits the selected handler and only then sends the mcp-response; there is no outer timeout around that await.
  • list_threads fans out to host managers with Promise.all, also without a per-host deadline. One non-settling host can therefore stall the whole call.
  • The other affected operations (list_projects, read_thread, create_thread, set_thread_title, send_message_to_thread, and set_thread_archived) likewise await renderer/app-server dependencies without a dispatcher-level deadline.

This also did not look like a generic app-server overload: the local state DB and thread inventory were readable, and the logs contained no "Server overloaded; retry later" response. Process accumulation may amplify the issue, but does not explain why a later task/turn recovers.

Suggested fixes:

  1. Put a deadline around every Desktop dynamic-tool handler and return a structured, retryable error.
  2. Re-register or revalidate renderer handlers when an automation task starts/resumes.
  3. Log a correlated request -> handler -> response lifecycle, including renderer activation/focus state.
  4. For side-effecting calls such as create_thread, return explicit delivered / not-delivered / uncertain status so retries cannot create duplicates.
Anionex · 1 month ago

Additional high-confidence reproduction on the current Codex App build. This appears to be the same failure mode, with a strong lid-open correlation even though macOS never entered system sleep.

Environment

  • Codex App 26.707.91948 (build 5440)
  • Bundled codex-cli 0.144.5
  • Darwin 25.4.0 arm64 arm
  • Local heartbeat automation whose prompt calls the Codex App dynamic tool create_thread
  • A sleep-prevention session remained active throughout the night

Timeline

Local time is UTC+8:

  • 2026-07-18 23:59:06: the scheduled heartbeat turn started normally.
  • 23:59:31: the model emitted codex_app.create_thread (call_zZZQfCcAzlcPXnNuAKgcJrui).
  • The Codex core/app-server remained alive, but no DynamicToolResponse arrived overnight.
  • 2026-07-19 08:26:34: pmset -g log recorded com.apple.powermanagement.lidopen.
  • 08:26:56: only 22 seconds after lid-open, the client submitted the pending DynamicToolResponse.
  • App-server recorded handler_duration_ms=30445215 (about 8h27m) for that tool call.

The eventual response was a normal client-side validation error for the requested model/reasoning combination. The important part is that the validation response itself was not delivered until immediately after lid-open.

Power evidence rules out system sleep

pmset -g log showed the same active PreventUserIdleSystemSleep assertion before and after lid close, including at 23:46:02, 23:46:19, and 00:01:19. There was no Sleep or DarkWake transition between lid close and the 08:26:34 lid-open event. The scheduler, model request, network, and Codex core all ran at the expected time.

This was therefore not a missed run or wake catch-up. The turn was live and blocked specifically while waiting for the Desktop client to service a dynamic tool request.

Repeated history

The same pattern has occurred repeatedly with codex_app.list_projects:

  • 2026-07-08 05:31:59 call -> 07:57:01 response; create_thread then returned immediately.
  • 2026-07-16 05:32:02 call -> 10:31:30 response; create_thread then returned in milliseconds.
  • 2026-07-18 05:30:46 call -> 10:51:44 response; create_thread then returned in milliseconds.

Across the affected scheduled runs, opening/activating the laptop consistently releases the pending app-tool call and only then allows the actual worktree thread to be created.

Source-level match

On current openai/codex main at 0fb559f0f6e231a88ac02ea002d3ecd248e2b515:

  • codex-rs/core/src/tools/handlers/dynamic.rs waits at rx_response.await without a deadline.
  • codex-rs/app-server/src/dynamic_tools.rs likewise waits at receiver.await without a deadline.

If the Desktop connection remains registered while its renderer/client handler is inactive, the request can therefore remain pending indefinitely instead of failing or retrying.

Expected behavior

When the local Mac is awake and Codex is running, a scheduled automation should not require an active/focused display or manual thread opening to service first-party app tools. At minimum, the dynamic-tool dispatcher should have a deadline and return a structured retryable error rather than leaving the automation in a misleading running state for hours.

Session ID: 019e967d-4375-7950-9c85-240ae2168f62

sankalp-phadnis · 22 days ago

Additional reproduction on a newer Desktop build (read_thread)

I hit the same failure mode on 2026-08-06, this time with read_thread rather than list_projects.

Environment

  • ChatGPT/Codex Desktop: 26.730.61639 (build 6234)
  • Bundled Codex CLI: 0.147.0-alpha.1.2
  • macOS, Apple Silicon
  • Naturally scheduled automation

Exact timeline

  • Automation task created: 09:31:00 IST
  • Execution began: 09:31:02 IST
  • read_thread call began: 09:34:20.730 IST
  • read_thread returned: 11:56:26.325 IST
  • Time blocked in that one call: 2h 22m 05.595s
  • Automation completed: 12:01:21 IST

The automation therefore started on time; this was not scheduler startup latency.

All other 27 paired tool calls in the turn took about 127.966 seconds combined. The single read_thread call accounted for approximately 94.5% of the total turn duration. The session rollout contains no events during the 2h22m gap.

The Mac did not sleep during the stall. The ChatGPT/Codex Electron process held a NoIdleSleepAssertion throughout the relevant window.

Opening the affected task at approximately 11:56 appeared to release the pending call, with the result arriving at that same time. I cannot prove the foreground action was causal from local telemetry, but the timing matches the behavior originally reported here. The target task subsequently reported notLoaded, which may be relevant to task-host loading or callback delivery.

Impact and expected behavior

A read-only task inspection can block the entire unattended automation for hours. Scheduled runs should not depend on a target task being opened or loaded in the UI. read_thread should return a snapshot, a structured notLoaded/unavailable response, or a bounded timeout; it should never remain pending indefinitely.

This also looks related to #35030, which reports naturally scheduled runs hanging in list_threads. Together these reproductions suggest the liveness problem affects multiple Desktop thread-management operations rather than only project listing.

Private session, turn, target-task, and tool-call identifiers are available through an OpenAI-controlled private feedback channel if maintainers need them.