Pinned Codex thread becomes detached from its local project and cannot continue: “Unable to send message — Select a project to continue”

Open 💬 2 comments Opened Aug 2, 2026 by mattLummus
💡 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.727.40816

What subscription do you have?

Pro

What platform is your computer?

Mac OS Tahoe 26.5.1 (Darwin 25.5.0 arm64 arm)

What issue are you seeing?

A previously working Codex thread in the ChatGPT/Codex desktop app became unusable because the app appears to have lost the thread’s association with its local project.

The thread is still visible, pinned, and readable. However, attempting to send any new message produces this dialog:

Unable to send message
Select a project to continue

The dialog only provides an OK button.

Reopening the same repository folder did not restore the thread or reconnect it to the project. The local project entry also shows “No chats”, even though the existing pinned thread was previously using that repository.

This is especially concerning because I have also experienced other Codex threads disappearing unexpectedly without being archived or intentionally deleted. There appears to be a broader reliability problem affecting thread persistence and project/thread associations.

What steps can reproduce the bug?

I do not yet have a reliable intentional reproduction path, but the failure occurred during normal use:

Open the Codex desktop app.
Work in a thread associated with a local repository.
Pin the thread and continue using it normally.
Later, return to the same thread.
Enter a new message and attempt to send it.

The app displays:

Unable to send message
Select a project to continue

Reopen the repository folder previously used by the thread.
Return to the pinned thread and attempt to send another message.

What is the expected behavior?

One of the following should occur:

The thread should retain its association with the local project and continue working normally.
Reopening the same repository should automatically restore the association.
The app should provide a clear Move to project, Reattach project, or Select repository for this thread action.
The app should never silently lose the metadata required to continue an active thread.

Additional information

Additional observations
The affected thread was pinned.
The thread had previously been functioning normally.
The repository still exists locally.
Reopening the repository did not repair the problem.
The project sidebar showed “No chats.”
I have separately experienced threads disappearing without being archived or deleted, suggesting this may be related to a wider regression involving thread persistence or project metadata.

The exact error dialog:

Unable to send message
Select a project to continue

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 26 days ago

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

  • #35867

Powered by Codex Action

andybergon · 3 days ago

Additional reproduction on ChatGPT/Codex Desktop 26.818.61809 build 7019, macOS 26.6.1 arm64:

  • create_thread explicitly targeted a saved local non-git project and returned a valid task
  • Initial session metadata recorded the intended project directory as cwd
  • The first runtime request reported zero workspace roots
  • A later read_thread returned cwd=/
  • Desktop then blocked composer sends with:
  • Unable to send message
  • Select a project to continue
  • The underlying task remained healthy: two send_message_to_thread follow-ups completed successfully, including one 18.6-second turn

This appears to narrow the failure to the project/workspace association used by the Desktop composer, rather than transcript loss or an unavailable backend task. I cannot confirm which persistence or reconciliation step dropped the association.

The verified workaround was to create a replacement task against the same saved project and copy in a concise handoff. I could not find a supported way to reattach the detached task in the UI.