›_ Codex Issues
Codex Issues / #39704

[Linux/NixOS][Intel i915] ChatGPT Desktop triggers GPU hang and freezes the display on launch

Open 💬 1 comment Opened Aug 20, 2026 by zaviro

What version of the Codex App are you using (From “About Codex” dialog)?

ChatGPT Desktop 26.818.21641; bundled Chromium 151.0.7922.170.

Packaging note: this is the official Linux application binary repackaged for NixOS by the llm-agents Nix flake, rather than an officially supported Ubuntu/Debian/Fedora package.

What subscription do you have?

Plus

What platform is your computer?

Linux 6.18.44 x86_64 unknown

Additional environment:

  • NixOS 26.11
  • niri 26.04 Wayland compositor
  • ChatGPT defaults to XWayland (--ozone-platform=x11)
  • Intel Raptor Lake-S UHD Graphics [8086:a782]
  • Kernel driver: i915
  • Mesa 26.2.0
  • Xwayland 24.1.13
  • xwayland-satellite 0.8.2
  • Display: 2560x1440 at 180 Hz over DisplayPort

What issue are you seeing?

Launching ChatGPT Desktop temporarily freezes the entire display. The kernel consistently attributes the freeze to the ChatGPT GPU process:

i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:859ffffb, in .ChatGPT-wrappe
 i915 0000:00:02.0: [drm] GPU error state saved to /sys/class/drm/card1/error
 i915 0000:00:02.0: [drm] .ChatGPT-wrappe context reset due to GPU hang

Behavior varies between launches:

  1. On some launches, the screen freezes once or twice, then ChatGPT recovers and remains usable.
  2. On other launches, the screen freezes and ChatGPT exits completely.
  3. Before rebooting into kernel 6.18.44, one occurrence also caused the display output to disconnect/reconnect and xwayland-satellite to exit with status 101.

During a launch that eventually recovered, two GPU hangs occurred eight seconds apart. Chromium then restarted its GPU process with software rendering:

--use-gl=disabled

The app was usable after that fallback. On the latest reproductions, the application exited after the GPU hang and no ChatGPT processes remained. No userspace coredump or Crashpad minidump was produced.

The current boot recorded six GPU hangs attributed to .ChatGPT-wrappe, including two separate launch-and-exit sequences:

20:03:30 GPU HANG ... .ChatGPT-wrappe [5198]
20:03:42 GPU HANG ... .ChatGPT-wrappe [6068]
20:03:42 xwayland-satellite exited
20:03:45 ChatGPT application scope ended

20:05:10 GPU HANG ... .ChatGPT-wrappe [6338]
20:05:10 xwayland-satellite exited
20:05:10 ChatGPT application scope ended

This does not look like an ordinary renderer stall: the kernel is resetting an i915 GPU context owned by ChatGPT at exactly the time the entire display freezes.

What steps can reproduce the bug?

  1. Log into a niri Wayland session on an Intel Raptor Lake-S iGPU using i915.
  2. Ensure no existing ChatGPT processes are running.
  3. Launch ChatGPT Desktop normally. It starts through XWayland.
  4. Wait approximately 15–30 seconds.
  5. Observe the entire display freeze.
  6. Check the kernel journal:
journalctl -k -b | grep -E 'GPU HANG|ChatGPT|context reset'

The ecode 12:1:859ffffb hang has reproduced on every tested fresh launch after the application/system update.

A previous system generation used Mesa 26.1.6, xwayland-satellite 0.8.1, kernel 6.18.42, and ChatGPT 26.810.52044. The affected generation updated several components simultaneously, so I have not yet isolated whether the regression originates in ChatGPT/Chromium, Mesa 26.2.0, or their interaction.

What is the expected behavior?

ChatGPT should initialize GPU acceleration without hanging the i915 render engine or freezing the entire desktop. If GPU initialization fails, it should fall back to software rendering without first causing repeated kernel GPU resets or exiting.

Additional information

The error signature is notable because ecode 12:1:859ffffb has previously appeared in Chromium/CanvasRenderer i915 GPU-hang regressions. Starting with --disable-gpu is the intended temporary workaround, but hardware acceleration should not be able to freeze the compositor/display during normal application startup.

I can provide a sanitized journalctl excerpt or the saved /sys/class/drm/card1/error GPU error state if useful.

View original on GitHub ↗

1 Comment

zaviro · 7 days ago

Additional controlled startup testing narrows this to the GL hardware-acceleration path.

--disable-gpu is not a usable workaround for this Linux build. With no existing ChatGPT instance running, launching:

chatgpt --disable-gpu

left the application without a window and produced this unhandled rejection:

Error: GPU access not allowed. Reason: GPU access is disabled through commandline switch --disable-gpu and --disable-software-rasterizer.

The process remained alive in the background without a renderer/window and had to be terminated.

A clean launch using Chromium's narrower GL fallback did work:

chatgpt --use-gl=disabled

Observed result:

  • ChatGPT remained on its default XWayland path (--ozone-platform=x11).
  • The main window and renderer processes initialized normally.
  • No display freeze occurred.
  • No new i915 GPU HANG or context-reset event appeared during observation.
  • The app remained responsive and usable.

This is also the same effective GPU-process state Chromium had selected automatically after two consecutive GPU hangs during one earlier launch. The difference is that passing --use-gl=disabled from startup avoids the hangs instead of waiting for recovery.

This result does not yet prove Mesa alone is responsible. It shows an interaction in the ChatGPT/Chromium GL acceleration path involving Mesa/i915. A controlled Mesa 26.2.0 -> 26.1.6 rollback while holding the ChatGPT and kernel versions constant would be needed to attribute the regression specifically to Mesa.