## System details

- Omarchy: `4.0.0-1`
- Kernel: `Linux 7.1.8-arch1-3 x86_64`
- Hyprland: `0.56.2-1`
- Steam: `1.0.0.87-1`
- CPU: AMD Ryzen 9 9950X3D 16-Core Processor
- GPU: AMD Radeon RX 9070/9070 XT/9070 GRE (`amdgpu`)
- Additional GPU: AMD Granite Ridge integrated graphics (`amdgpu`)
- Reproduction application: Sandustry's native Linux Electron build

## What's wrong?

An Electron application may start and remain running but create no visible window or Hyprland client when it inherits Omarchy's globally forced Ozone/Wayland environment. This was reproduced with Sandustry's native Linux Electron build: the process starts, but no Sandustry client appears in `hyprctl clients`.

Omarchy's default Hyprland environment in `/usr/share/omarchy/default/hypr/envs.lua` globally exports:

```lua
hl.env("ELECTRON_OZONE_PLATFORM_HINT", "wayland")
hl.env("OZONE_PLATFORM", "wayland")
```

The application opens normally when both variables are removed only for that process:

```bash
env -u ELECTRON_OZONE_PLATFORM_HINT -u OZONE_PLATFORM %command%
```

This isolates the failure to the globally forced Ozone/Wayland environment inherited by the application's Electron/Chromium runtime. It is not a Steam-specific issue, window-placement issue, or Hyprland window-rule problem: without the workaround, no window is created at all.

## Steps to reproduce

1. Use an unmodified Omarchy 4.0.0 Hyprland environment, where both `ELECTRON_OZONE_PLATFORM_HINT` and `OZONE_PLATFORM` are set to `wayland`.
2. Install Sandustry's native Linux Electron build as a reproducible affected application.
3. Launch it without compatibility layers or environment overrides.
4. Observe that the application process remains running, but no window appears.
5. Run `hyprctl clients` and observe that no application window/client exists.
6. Launch it with both inherited variables removed:

   ```bash
   steam application launcher
   env -u ELECTRON_OZONE_PLATFORM_HINT -u OZONE_PLATFORM %command%

   ~/.config/hypr/envs.lua
   hl.env("ELECTRON_OZONE_PLATFORM_HINT", "")
   hl.env("OZONE_PLATFORM", "")
   ```

7. Observe that the application now creates its window and opens normally.

## Expected behavior

Electron/Chromium applications should be able to select a working Ozone backend and create a window under Omarchy. Omarchy's global defaults should not prevent applications with incompatible Electron versions from starting.

## Actual behavior

Because Omarchy globally forces both Ozone variables to `wayland`, an affected Electron application can run without ever creating a window. Removing both variables for the process fixes the reproduced failure.

## Suggested resolution

Please consider avoiding a global hard requirement for native Wayland for all Electron/Chromium applications. Possible approaches include using an automatic backend hint, leaving `OZONE_PLATFORM` unset globally

The confirmed workaround is:

```bash
env -u ELECTRON_OZONE_PLATFORM_HINT -u OZONE_PLATFORM %command%

~/.config/hypr/envs.lua
hl.env("ELECTRON_OZONE_PLATFORM_HINT", "")
hl.env("OZONE_PLATFORM", "")
```

## Additional diagnostics

The standard reporting command documented by the installed Omarchy AI skill is unavailable on this release:

```text
$ omarchy debug --no-sudo --print
Unknown Omarchy command: omarchy debug --no-sudo --print
Run 'omarchy commands --all' to discover available commands.
```

## Duplicate search

Existing reports cover other Chromium/Ozone Wayland failures, but the duplicate search did not find this specific global-environment failure mode and its two-variable workaround.