Codex app freezes when adding chats to a task

Resolved 💬 4 comments Opened Jul 10, 2026 by CapedBojji Closed Jul 10, 2026
💡 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.707.31428 (bundle version 5059)

What subscription do you have?

Unknown

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When adding chats to a task in the Codex desktop app, the app freezes. The pet/assistant indicator still shows that it is thinking, but the chat area shows no response text. The input box also becomes unusable: I cannot type in it after the freeze starts.

This leaves the task stuck and requires restarting/recovering the app session.

What steps can reproduce the bug?

  1. Open the Codex desktop app on macOS.
  2. Open an existing task.
  3. Use the app flow to add chats to that task.
  4. After adding chats, observe that the app becomes unresponsive:
  • the pet still shows thinking/activity,
  • the chat pane shows no text,
  • the message input cannot be typed into.

What is the expected behavior?

Adding chats to a task should complete without freezing the UI. The chat should continue rendering text normally, and the input box should remain interactive.

Additional information

Reported from a user session on July 10, 2026. I searched existing issues for related phrases like “adding chats”, “add chats task freeze”, and “pet thinking freezes chat” and did not find an obvious duplicate.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32033

Powered by Codex Action

fibo-blip · 1 month ago

I can reproduce the same issue on Windows 11 with Codex App 26.707.3748.0 while the agent runtime is running in WSL.

Reproduction:

  1. Open an existing task with an active Goal and multiple subagents.
  2. Open the side chat while the task is running.
  3. Add a follow-up/comment in the side chat.
  4. Click Add to task.
  5. The entire UI immediately becomes unresponsive. The task view, input box, and other UI controls cannot be used.

Additional diagnostics:

  • The UI remained frozen for several minutes.
  • The main Desktop process still reported Responding=True, but one Chromium renderer continuously consumed roughly one CPU core.
  • The WSL app-server remained alive.
  • The active Goal and spawned subagents continued executing.
  • Session rollout files continued to be appended, so the backend was still making progress while the renderer/UI was frozen.
  • The affected task was long-running and tool-heavy, with a large local rollout (about 185 MB). This may amplify the issue, but I cannot confirm that it is required for reproduction.

Expected behavior: Add to task should merge the side-chat context without blocking the renderer or making the task UI unusable.

fibo-blip · 1 month ago

Additional recovery/reproduction evidence:

  • The backend turn and all subagents completed successfully, but the affected thread remained a UI-only failure.
  • Other existing chats open and work normally in the same app session.
  • Opening the one thread that received the side-chat via Add to task immediately returns the renderer to a sustained one-core CPU loop and makes the UI unresponsive.
  • The desktop log repeatedly requests thread/turns/list for that thread, with multi-second responses, while the renderer is saturated.
  • A full app restart reproduces the problem if that thread is restored. Moving only Chromium Session Storage aside (after backup) lets the app start on a neutral screen and other chats remain usable; reopening the affected thread reproduces the freeze again.
  • Chat/session data was not deleted. This isolates the trigger to rendering/resuming the affected thread after Add to task, rather than WSL runtime failure or a general app startup problem.
Sunspark888 · 1 month ago

将含有很长的语音对话传进去的时候会卡死,其他没用卡