Repository navigation
[macOS desktop] Agent codex_app thread and automation tools still hang on 26.814.41407 build 6720 #40900
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.814.41407 (build 6720)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.5.0 arm64 arm (macOS 26.5.2, Apple Silicon)
What issue are you seeing?
Agent-invoked codex_app operations can remain pending indefinitely while the desktop UI and ordinary local operations remain responsive. This appears similar to #37668 and #38571, but reproduces on the newer desktop build 6720.
The affected operations included cross-thread messaging, automation creation and read-only thread listing. No structured timeout or error was returned.
Later, an automation_update call to pause an existing automation completed immediately and the resulting configuration change was verified on disk. This suggests the failure is intermittent and may vary by operation or app-service state, rather than representing a permanently unavailable handler.
What steps can reproduce the bug?
Step 1: From an active local Codex task, invoke codex_app__send_message_to_thread for an existing ChatGPT/Work chat. The call remains pending beyond 60 seconds and provides no structured error.
Step 2: Invoke codex_app__automation_update to create a harmless one-off heartbeat. The call likewise remains pending and the proposed automation is not created.
Step 3: Invoke read-only codex_app__list_threads. It also remains pending without a structured result.
Step 4: Fully restart the desktop app and repeat. The behaviour recurs.
During the same period, local filesystem reads and writes succeed; shell commands succeed promptly; the desktop UI remains usable; no approval request appears; and an existing automation configuration remains readable and valid.
No session ID, prompts, paths or thread identifiers are included because they are unnecessary to reproduce the failure and may contain private information.
What is the expected behavior?
Every advertised codex_app operation should either complete promptly or return a structured, bounded error. A failed create operation should unambiguously state whether any object was created.
Additional information
This appears related to #37668 (agent thread tools hang before reaching AppServerConnection), #38571 (list_threads reaches app server but never completes while the UI remains healthy), and #39148 (related thread-management hang family on a later build).
The reproduction does not require sharing prompts, local paths, thread identifiers or the contents of local files. Those details have intentionally been omitted. No screenshots or raw logs are attached.
Activity
[-][macOS] codex_app tools hang on build 6720[/-][+][macOS desktop] Agent codex_app thread and automation tools still hang on 26.814.41407 build 6720[/+]dengdingchang commentedon Sep 21, 2026
I can reproduce what appears to be the same issue on a newer macOS Codex Desktop build.
Environment
codex_app.list_threadsObserved behavior
During an agent task,
list_threads(limit: 10)was invoked as part of a thread-status inspection.The call remained pending for approximately 96.982 seconds without returning a result or a structured timeout/error.
Because there was no visible progress during that period, I manually stopped the run.
The session rollout shows:
00:00:33local time.00:00:45, an execution path invokedget_goalandlist_threads(limit: 10).list_threadsremained pending for approximately 96.982 seconds.CancelledErrorat approximately00:02:22.task_completeat approximately00:02:43.Importantly, the final
completed/idlestate was the result of cancellation/cleanup and should not be interpreted as the original task having completed normally.Other direct thread inspection paths were usable, so the task itself was not performing a long-running computation. The blocking operation was specifically the thread enumeration path.
Impact
This creates two problems:
list_threadscan block an agent's critical path for an unbounded period.It becomes especially problematic when
list_threadsis used inside aPromise.allor another orchestration step, because one pending enumeration prevents otherwise completed operations from producing a result.Expected behavior
list_threadsshould either:Cancellation should also preserve a clear termination reason such as
cancelled_by_user, rather than allowing the final lifecyclecompleted/idlestate to be confused with successful task completion.As a local workaround, I am avoiding
list_threadson the critical path when a thread ID is already known and using directread_thread/wait_threadsaccess instead.I can provide a redacted rollout/session ID through the in-app feedback channel if that would help diagnose the app-server/tool-routing layer.