codex - 💡(How to fix) Fix Codex Desktop: Cmd+Cmd app snapshot attaches to both main and side chat composers

What happened?

In Codex Desktop on macOS ( 26.527.31326 ), pressing Cmd+Cmd to use the application snapshot feature attaches the captured screenshot to both visible composers when a side chat is open:

• the main conversation composer
• the side chat composer

This is surprising because the snapshot is often meant for only one of those contexts. If the user captured the snapshot to ask a side-chat-only question, returning to the main conversation requires manually removing the unrelated screenshot from the main composer.

Expected behavior

The application snapshot should be attached only to the currently active/focused composer, or at least to a single clearly selected target composer/thread.

If the side chat composer is focused, the snapshot should not also be added to the main conversation composer.

Actual behavior

The same application snapshot attachment appears in both the main conversation draft and the side chat draft.

Reproduction steps

1. Open Codex Desktop on macOS.
2. Open a main conversation.
3. Open a side chat beside it.
4. Focus the side chat composer.
5. Press Cmd+Cmd to trigger the application snapshot feature.
6. Observe that the captured screenshot appears in both composers.

Environment

• Platform: macOS
• Product: Codex Desktop / Codex app UI
• Repo checked: openai/codex

Investigation notes

I looked through the public openai/codex repository and could not find the macOS Cmd+Cmd snapshot capture entrypoint or Desktop UI implementation. There are no Swift/React/Electron/Tauri desktop-client sources in the checkout that appear to own this UI path.

From the public Rust app-server/TUI code, image input submission appears thread-scoped rather than globally broadcast:

• TurnStartParams carries a specific thread_id and input.
• UserInput supports Image and LocalImage payloads.
• turn_start_inner loads exactly params.thread_id before submitting the input.
• thread/inject_items is also thread-scoped and writes model-visible history, not unsent composer draft state.
• The TUI image attach path only mutates the active ChatComposer attachment state.

That makes this look like a Desktop client state-routing bug: the snapshot completion handler is probably writing the attachment into shared/global composer draft state, or broadcasting the same attachment event to every mounted composer, instead of targeting the active/focused composer or explicit threadId/composerId.

If this repository is not the owner for Codex Desktop issues, could this be routed to the Desktop/macOS client team?