Desktop: Computer Use / Browser Use PiP paints large black box when hovering close (X) control
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
- Open Codex Desktop on macOS.
- Start a task that surfaces a live overlay:
- Computer Use with iOS Simulator, or
- Browser Use PiP / live screenshot overlay.
- Wait until the floating preview appears (phone frame / browser snapshot).
- Move the cursor over the overlay so the hide (X) and pop-out controls appear.
- 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):
2. Hovering the X control — large black box (bug):
3. Controls visible with soft circular shadow (hover near phone, not on X):
4. Hover near controls, black box not fully triggered:
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:
_hoverOverlayLayer/ control-fog shape frame (_controlFogShapeFrame) expands to a large solid black fill instead of a small frosted pill, or- 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 messagesbrowser-use-pip/codex/toolSurfacepresentation 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)
- Reproduce with Computer Use PiP + Simulator (or Browser Use PiP) on macOS.
- In
PIPStackController, inspectsetHoveredControlIdentifier:/updateHoverAtContentPoint:when identifier == hide control. - Verify
_controlFogShapeFrameand fog mask layers stay sized to the control chrome, not a large top rect. - Ensure backdrop/blur failure does not paint opaque
blackColorunder the full fog container. - Confirm
_hoverOverlayLayeronPIPStackItemis 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.
3 Comments
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.
I can reproduce this exact PiP close-control hover glitch on a different Apple Silicon environment:
26.707.7222115.5Hovering 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.
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.