Product impact
Describe the bug
On macOS, the signed-in transparent main shell can render normally while visible controls stop accepting clicks. Navigation buttons do not select, and search or composer fields do not reliably receive focus, making the shell feel like it is not a real application window.
The frameless appearance itself is understood to be intentional. The defect is that visible content sometimes behaves like the transparent dead area and passes mouse events through instead of remaining interactive.
To Reproduce
The failure is intermittent and currently appears to depend on shell runtime state:
- Launch Omi Desktop while signed in.
- Open the main shell from the floating/notch control.
- Navigate among Chat, Brain, Tasks, Rewind, or Apps and try to focus a search or composer field.
- In the affected state, the shell remains visible but clicks over visible controls do not select or focus them.
Current behavior
Visible controls can become non-interactive while the transparent main shell remains on screen.
This is not a general input failure on the Mac. On the same machine, a side-by-side named comparison bundle opened the same signed-in transparent shell, navigated from Chat to Brain, accepted text in Brain search, and remained at low CPU. That points to a build, route, or window-state boundary rather than a machine-wide macOS failure.
Expected behavior
Only transparent dead margins should pass clicks through. Every visible panel, navigation control, button, search field, and composer should keep the main window interactive.
Screenshots
The affected and working states can look identical, so a static screenshot does not show the mouse-event failure. A focused diagnostic capture can be added once the state is reproduced deterministically.
user ID (can we access the user info to validate the bug?):
Not included in a public issue. It can be provided privately if needed.
Smartphone + device (please complete the following information):
- Device: MacBook Pro (Mac16,5), Apple M4 Max, 36 GB
- OS: macOS 27.0, build 26A5421a
- Browser: N/A, desktop app
- App Version: Omi Desktop 0.12.213, build 12213
Additional context
Current upstream ShellMouseInterceptionSync updates the whole window's ignoresMouseEvents state at 30 Hz from InkGlassHitRegions. A missing or stale visible-surface registration during a shell rebuild could therefore classify visible content as dead air. This is a suspected boundary, not yet a confirmed root cause.
A local diagnostic build using conventional AppKit window chrome restored stable interaction, but that changes Omi's documented transparent-shell product design and is not proposed as the upstream fix. The upstream fix should preserve click-through for dead margins while behaviorally proving that visible controls remain interactive through route and hosting-view changes.
Related work:
Product impact
Describe the bug
On macOS, the signed-in transparent main shell can render normally while visible controls stop accepting clicks. Navigation buttons do not select, and search or composer fields do not reliably receive focus, making the shell feel like it is not a real application window.
The frameless appearance itself is understood to be intentional. The defect is that visible content sometimes behaves like the transparent dead area and passes mouse events through instead of remaining interactive.
To Reproduce
The failure is intermittent and currently appears to depend on shell runtime state:
Current behavior
Visible controls can become non-interactive while the transparent main shell remains on screen.
This is not a general input failure on the Mac. On the same machine, a side-by-side named comparison bundle opened the same signed-in transparent shell, navigated from Chat to Brain, accepted text in Brain search, and remained at low CPU. That points to a build, route, or window-state boundary rather than a machine-wide macOS failure.
Expected behavior
Only transparent dead margins should pass clicks through. Every visible panel, navigation control, button, search field, and composer should keep the main window interactive.
Screenshots
The affected and working states can look identical, so a static screenshot does not show the mouse-event failure. A focused diagnostic capture can be added once the state is reproduced deterministically.
user ID (can we access the user info to validate the bug?):
Not included in a public issue. It can be provided privately if needed.
Smartphone + device (please complete the following information):
Additional context
Current upstream
ShellMouseInterceptionSyncupdates the whole window'signoresMouseEventsstate at 30 Hz fromInkGlassHitRegions. A missing or stale visible-surface registration during a shell rebuild could therefore classify visible content as dead air. This is a suspected boundary, not yet a confirmed root cause.A local diagnostic build using conventional AppKit window chrome restored stable interaction, but that changes Omi's documented transparent-shell product design and is not proposed as the upstream fix. The upstream fix should preserve click-through for dead margins while behaviorally proving that visible controls remain interactive through route and hosting-view changes.
Related work: