[macOS] Dropping an existing conversation into a new chat does not insert a reference

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

26.908.40834, build 8881 (verified from the installed app bundle).

What subscription do you have?

Not included in this report.

What platform is your computer?

macOS 26.2 (25C56), Apple Silicon / arm64.

What issue are you seeing?

Dragging an existing conversation from the sidebar into the input box of a new conversation no longer inserts a chat reference.

The drag starts and the conversation can be moved with the pointer, but releasing it over the new conversation's input box does not create a reference chip/card. This prevents me from bringing a previous conversation into a new conversation as context using the drag-and-drop workflow that previously worked for me.

This report concerns reference insertion before sending a message, rather than the model failing to read an already-inserted reference.

What steps can reproduce the bug?

1. Open the desktop app with existing conversations available in the sidebar.
2. Start a new conversation.
3. Drag an existing conversation from the sidebar into the new conversation's input box.
4. Release the mouse button.
5. Observe that no chat reference chip/card is inserted.

These are the user's reported steps and result. Automated UI reproduction was not possible because the computer-use tool cannot operate the Codex app itself.

What is the expected behavior?

Dropping an existing conversation into a supported new conversation's input box should insert a reference to that conversation. If references are unavailable in the current mode, the UI should clearly explain that restriction instead of silently doing nothing.

Additional information

Reported on September 15, 2026.

Read-only inspection of the installed frontend bundle found that:

• The sidebar-to-composer thread-reference drag/drop implementation and the “Drop to reference chat” overlay text are still present.
• For a new conversation, reference capability is checked against the remotely evaluated default thread_tools feature; existing conversations use a separately stored per-conversation reference-capability value.
• The reference drop target is conditionally registered based on capability and composer state.

These observations are troubleshooting leads only. The actual runtime flag value has not been verified, and this report does not establish that a disabled flag is the cause. A drop-target registration/hit-testing issue or another composer-state condition remains possible.

The following comparison tests have not yet been confirmed:

• Whether inserting the same conversation using @ works in a new conversation.
• Whether dropping the same conversation into an existing conversation works.
• Whether a full app restart changes the behavior.

Historical issues #26850 and #29322 mention thread_tools, but describe crashes/blank conversations in older versions. They are not confirmed duplicates of this pre-send drag/drop insertion failure.

Please investigate whether reference capability is being initialized correctly for new conversations and whether the composer can silently reject an otherwise draggable sidebar conversation.

No private conversation contents, session identifiers, account identifiers, or full local logs are included.

Start by inspecting the installed frontend bundle's sidebar-to-composer thread-reference drag/drop implementation, the “Drop to reference chat” overlay, and conditional drop-target registration. Compare capability initialization and composer state for new versus existing conversations, then check the reported @ insertion and alternate drop cases. Done means dropping a conversation into a supported new chat reliably inserts a reference or clearly explains why it is unavailable.