Desktop: Computer Use / Browser Use PiP paints large black box when hovering close (X) control

Open 💬 3 comments Opened Jul 12, 2026 by fede-oss

What version of the Codex App are you using?

26.707.51957 (build 5175)

What subscription do you have?

N/A (reported with repro screenshots)

Which OS are you seeing the problem on?

macOS 15.7.7 (24G720), Apple Silicon

Bug summary

When Codex shows a floating Computer Use / Browser Use PiP overlay (e.g. iOS Simulator preview or browser use live view), hovering the close (X) control paints a large solid black rectangle over the top of the preview. The X / pop-out controls sit on top of that black box and the preview is partially obscured.

This is a pure UI glitch on the remote-hosted PiP control chrome — dismissing still works, but the hover feedback is broken.

Steps to reproduce

  1. Open Codex Desktop on macOS.
  2. Start a task that surfaces a live overlay:
  • Computer Use with iOS Simulator, or
  • Browser Use PiP / live screenshot overlay.
  1. Wait until the floating preview appears (phone frame / browser snapshot).
  2. Move the cursor over the overlay so the hide (X) and pop-out controls appear.
  3. Hover specifically over the X close control.

Expected

Hover on X should show a small, translucent / frosted control highlight (or none), without covering a large region of the preview with opaque black.

Actual

A large solid black rectangular region appears over the top of the PiP (including device chrome). White X + pop-out icons remain visible on top of the black box. Moving the cursor away restores the normal soft control fog / shadow.

Screenshots

1. Normal overlay (no hover on X):

!Normal PiP overlay

2. Hovering the X control — large black box (bug):

!Black box on X hover

3. Controls visible with soft circular shadow (hover near phone, not on X):

!Soft control shadow

4. Hover near controls, black box not fully triggered:

!Hover near controls

Technical investigation notes (for maintainers)

This overlay is not implemented in the public openai/codex CLI sources. On macOS it is rendered by the Desktop app’s remote-hosted PiP stack:

| Layer | Location |
| --- | --- |
| Native PiP host | Contents/Resources/native/sky.node |
| Controller | PIPStackController |
| Content view | PIPStackContentView (updateHoverFromCurrentMouseLocation, updateHoverAtContentPoint:) |
| Close control | _hideControlLayer / _hideControlIconLayer / _hideControlFrame |
| Pop-out control | _placementControlLayer + assets remote-hosted-pip/pop-out-window-egg@3x.png |
| Control material | _controlFogContainerLayer, _controlFogBackdropLayer, _controlFogBlurMaskSourceLayer, _controlFogDynamicShadowBackdropLayer* |
| Per-item hover | PIPStackItem._hoverOverlayLayer |

Likely failure mode: when hoveredControlIdentifier becomes the hide (X) control, either:

  1. _hoverOverlayLayer / control-fog shape frame (_controlFogShapeFrame) expands to a large solid black fill instead of a small frosted pill, or
  2. the dynamic shadow / blur-mask (_controlFogDynamicShadowBackdrop*, CABackdropLayer / CIGaussianBlur) fails and falls back to an opaque black backdrop while control icons are forced light (setControlIconWhiteAmount: / contrast sampling).

Electron glue also references this stack via:

  • remote-hosted-pip-* IPC messages
  • browser-use-pip / codex/toolSurface presentation upsert
  • feature flag cuaPIP

A public PR against openai/codex cannot fix this: the bug lives in the closed-source Desktop native module (sky.node / PIP stack), not the open-source CLI.

Suggested fix direction (internal)

  1. Reproduce with Computer Use PiP + Simulator (or Browser Use PiP) on macOS.
  2. In PIPStackController, inspect setHoveredControlIdentifier: / updateHoverAtContentPoint: when identifier == hide control.
  3. Verify _controlFogShapeFrame and fog mask layers stay sized to the control chrome, not a large top rect.
  4. Ensure backdrop/blur failure does not paint opaque blackColor under the full fog container.
  5. Confirm _hoverOverlayLayer on PIPStackItem is not incorrectly sized when only the hide control is hovered.

Impact

  • Blocks clean interaction with live PiP previews (Simulator / Browser Use).
  • Looks like a serious rendering failure; easy to hit during normal “close the overlay” usage.
  • Does not appear to crash or break dismiss functionality, but is highly visible.

Related (different bugs)

Other “black box/overlay” reports exist for plugins page / pets / Windows chrome, but none describe PiP close-control hover specifically. Happy to close as duplicate if an internal ticket already tracks the control-fog hover regression.

View original on GitHub ↗

3 Comments

fede-oss · 1 month ago

Screenshots attached in the issue body from the original screen recording (iOS Simulator Computer Use PiP on macOS). The black rectangle appears specifically when the cursor is over the close (X) control of the remote-hosted PiP chrome.

Liu-Lin-Hai · 1 month ago

I can reproduce this exact PiP close-control hover glitch on a different Apple Silicon environment:

  • Codex Desktop: 26.707.72221
  • macOS: 15.5
  • Hardware: Apple M4 (arm64)

Hovering the top-left X control produces the same large black rectangle. I filed #33277 before this duplicate was detected and am closing it in favor of this issue.

gmaltsev · 1 month ago

This got broken after the latest update that merged codex and chatgpt. So annoying, hitting one bug after the other with every update. For me codex can't even open a proper in-app browser tab, it always opens a PiP thing that can only be moved around and automatically disappears after ~10s. The in-app browser is completely unusable.