[Linux/Wayland] Voice orb transparent window blocks clicks far outside visible controls on Hyprland

What version of the Codex App are you using?

Installed Arch package: openai-codex-desktop 26.901.51231-1 (version from package metadata, not the About dialog). Bundled Electron: 42.3.0.

What subscription do you have?

Not included in this report; the observed problem concerns the native overlay window and pointer input.

What platform is your computer?

• Arch Linux / Omarchy, Hyprland 0.56.2, native Wayland.
• Linux 7.2.3-arch1-3 x86_64 unknown
• Affected display: 1920 × 1200, scale 1.25 (logical 1536 × 960), non-zero monitor origin in the desktop layout.
• App launched with --ozone-platform=wayland.

What issue are you seeing?

The realtime voice orb and its microphone/audio/stop controls occupy only a small visible area, but their transparent native window intercepts pointer input over a much larger rectangle. Underlying navigation, web content, and browser annotation comment input cannot be clicked within that invisible area. Moving the orb merely moves the obstruction elsewhere.

During diagnosis, Hyprland reported an approximately 772 × 1890 logical-pixel floating window for the voice overlay, exceeding the display's logical height. The main app and voice overlay share class chatgpt and title ChatGPT. The annotation comment window is titled Browser comment.

Additional observations during the same session:

• Window borders exposed the oversized transparent overlay bounds. Removing borders did not solve pointer interception.
• Pinning the voice window made workspace switching effectively instantaneous, but did not fix the invisible input area.
• Super + left-drag moved the voice window; dragging the visible orb itself did not reliably move it.
• Browser annotation interaction sometimes coincided with the voice overlay being recreated and returning to a central position. Annotation comment visibility/position also had problems. These may be separate focus/geometry issues; this report's primary reproducible defect is the oversized pointer-blocking area.

What steps can reproduce the bug?

1. Launch the Linux desktop app in a Hyprland Wayland session with 125% display scaling.
2. Start a realtime voice conversation and leave its floating orb visible.
3. Put another interactive window or the in-app browser behind the orb.
4. Attempt to click well above and beside the visible orb and controls.
5. Move the orb with the compositor's move-window gesture and repeat.
6. Optionally open a browser annotation and try to enter its comment while voice remains active.

Observed: a large transparent rectangle blocks the underlying application. Voice controls themselves remain usable. The issue is not limited to clicks directly on the visible orb.

What is the expected behavior?

Only the visible interactive overlay area should intercept clicks. Transparent space around it should allow interaction with the underlying app. The overlay should retain a usable position while annotations and other windows receive focus.

Additional information

We tested a local code change in an isolated copy of the installed app, without modifying the installed package. This is diagnostic evidence, not a proposed production-ready patch:

• For the Linux native avatar layout, constrain window bounds to the mascot, controls and any actual auxiliary tray, with small padding, instead of the much larger animation/reserved surface.
• Do not reserve the default native tray dimensions when there is no actual tray and this is not a quick-chat presentation.
• Preserve relative content coordinates when computing the smaller native window bounds.

An initial compact-bounds test reduced the reported window to roughly 383 × 364 but still left excessive unused space above/right. Removing the unused default tray reservation and reducing padding in a second test produced a compact area that the user confirmed was very good. This supports investigating overlay bounds and input-region handling; it does not establish whether Electron/Wayland input-shape support also contributes. Expanded trays/captions and other presentation states have not been exhaustively tested.

Separate local Hyprland rules disabled border/shadow/blur on these floating auxiliary windows and pinned the voice window. Those rules alone did not resolve the transparent click-blocking area. Compositor resize requests returned success without reducing the original app-managed bounds.

Switching to XWayland was not a usable workaround in this setup: an earlier test also affected scaling and external dictation behavior, so it was reverted. These are observations, not a claim of a shared root cause.

Related, but not the same request: #43577 asks for tiled voice controls on Omarchy/Hyprland. This report asks for correct transparent-overlay pointer behavior in the existing floating presentation.

No personal screenshots, chat transcripts or application logs are attached. The findings above were gathered during local testing and this report was prepared and posted with the affected user's authorization.

Start by tracing the Linux native avatar layout and the voice overlay's window bounds and input-region handling; reproduce the issue in a native Wayland Hyprland session with 125% scaling and the voice orb active. Done means transparent space no longer intercepts clicks outside the visible controls, while the overlay remains usable across its tested presentation states.