Chrome side panel: existing Codex Desktop conversations cannot access the selected Chrome tab

What variant of Codex are you using?

ChatGPT Chrome extension side panel connected to Codex Desktop on macOS.

Observed local bundled Chrome plugin version: 26.730.61639.

Summary

An existing conversation that was originally started in Codex Desktop can be opened in the ChatGPT Chrome extension side panel, but the resumed conversation cannot see or control the Chrome tab hosting the side panel.

This is specifically a thread-origin/resume problem. The extension side panel is running and supplies the selected tab's URL and tab ID to the conversation, but the resumed Desktop-originated thread does not receive the callable Chrome page-context or browser-control capability.

Reproduction steps

1. Start a conversation in Codex Desktop.
2. Continue using that conversation normally in Desktop.
3. Open the same existing conversation from the ChatGPT Chrome extension side panel.
4. Keep the side panel open on a normal Chrome tab.
5. Ask the conversation to inspect, read, or control the current Chrome tab.

Actual behavior

• The existing conversation and its history load in the Chrome side panel.
• The turn receives metadata identifying the selected Chrome tab, including its URL and tab ID.
• However, the runtime does not expose the page-context/browser-control tool required to read or control that tab.
• The assistant therefore knows which tab is selected but cannot see the rendered page or interact with it.
• In this reproduction, the original Desktop thread's workspace/MCP execution context also did not transfer, despite the conversation history transferring.

This creates a misleading partial connection: the conversation is visibly running inside the extension and receives tab metadata, but it lacks the extension capability needed to operate on that tab.

Expected behavior

When an existing Codex Desktop conversation is opened in the ChatGPT Chrome extension side panel, it should acquire the side panel's current Chrome-tab visibility and control capabilities, regardless of where the conversation was originally created.

If cross-surface capability attachment is intentionally unsupported, the UI should explicitly warn that Desktop-originated conversations opened in the extension cannot access the current tab.

Scope clarification

This is distinct from:

• #21598: Chrome plugin unavailable generally because of provisioning, gating, or region.
• #31706: openTabs() succeeds but a later claimTab() or control operation loses the browser handle.
• #32610: selecting a local Codex project when creating a new side-panel chat.

Here, the key condition is opening an existing Desktop-originated conversation in the Chrome side panel. The side panel supplies tab metadata, but the resumed thread receives no callable Chrome-tab access.