Plugin fullscreen remains blank until window resize or conversation navigation

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

26.901.22334

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

When a plugin switches from inline mode to fullscreen, the plugin fullscreen area becomes blank.

The fullscreen request is accepted and the reported display mode changes to fullscreen, but the plugin document remains hidden and receives zero fullscreen constraints.

Runtime state while the fullscreen view is blank:

{
  "displayMode": "fullscreen",
  "visibilityState": "hidden",
  "maxWidth": 0,
  "maxHeight": 0,
  "viewportWidth": 736,
  "viewportHeight": 485,
  "contentExists": true,
  "contentHasNonZeroLayoutBounds": true
}

The plugin content exists, has completed layout, and is not hidden by its own CSS. However, the Codex host still reports the document as hidden and does not provide valid fullscreen bounds.

The blank view can be recovered by either:

• Changing the Codex window width or sidebar width.
• Switching to another conversation and then switching back.

After changing the window or sidebar width, the runtime state becomes:

{
  "displayMode": "fullscreen",
  "visibilityState": "visible",
  "maxWidth": 647,
  "maxHeight": 976,
  "viewportWidth": 647,
  "viewportHeight": 976
}

No plugin content or application-state change is required for recovery. No JavaScript exception or explicit error message is shown.

What steps can reproduce the bug?

1. Open a conversation containing a plugin that supports inline and fullscreen display modes.
2. Open the plugin in inline mode.
3. Switch the plugin to fullscreen.
4. Observe that the plugin fullscreen area is blank.
5. Change the Codex window width or sidebar width.
6. Observe that the plugin immediately appears.
7. Alternatively, switch to another conversation and then return to the affected conversation.
8. Observe that the plugin also appears after conversation navigation.

A minimal fullscreen request is:

await window.openai.requestDisplayMode({
  mode: "fullscreen"
});

The request resolves successfully and reports fullscreen, even while the document remains hidden with zero fullscreen constraints.

Repeating the fullscreen request does not recover the view. Returning to inline mode and entering fullscreen again also does not reliably recover it.

This is a UI-lifecycle issue and is not associated with token usage, context-window usage, or a specific session ID.

What is the expected behavior?

After Codex accepts a plugin fullscreen request, it should:

1. Attach and activate the plugin fullscreen view.
2. Apply valid non-zero fullscreen bounds.
3. Mark the plugin document as visible.
4. Render the plugin immediately without requiring a window resize, sidebar resize, or conversation navigation.

Additional information

The following recovery attempts from inside the plugin document do not work:

• Repeating the fullscreen request.
• Performing an inline-to-fullscreen round trip.
• Dispatching a synthetic resize event.
• Triggering focus or local layout recalculation.
• Changing the plugin DOM dimensions.
• Sending an intrinsic-height notification.
• Triggering a local compositor repaint.

Only host-level layout or activation actions recover the view:

• Changing the Codex window or sidebar width.
• Navigating to another conversation and returning.

This suggests a Codex Desktop plugin-view activation or bounds-synchronization issue during the fullscreen transition. The host appears to accept fullscreen mode before the fullscreen view has been made visible and assigned valid bounds.

Start by reproducing the inline-to-fullscreen transition described in the issue and inspect the host plugin-view activation and bounds synchronization path. Compare the state before and after a window resize or conversation navigation; done means fullscreen immediately becomes visible with non-zero bounds without either recovery action.