[Linux ARM64][DGX Spark] ChatGPT launch crashes GNOME/RDP; adding video/render groups resolves it

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

Official ChatGPT desktop app for Linux, Debian package chatgpt version 26.901.31953, ARM64. Installed from the official download page using chatgpt_arm64.deb. The version was observed during installation and confirmed afterward with dpkg-query.

This concerns the Linux desktop application at /usr/lib/chatgpt/ChatGPT, including its Codex surface, not the standalone CLI.

What subscription do you have?

Not collected for this report. The failure occurred during desktop application startup.

What platform is your computer?

NVIDIA DGX Spark / GB10, accessed from Windows 11 using Microsoft Remote Desktop (mstsc.exe).

The following inventory was collected after recovery; it was not captured atomically at the first crash:

Component	Observed value
OS	Ubuntu 24.04.4 LTS
Kernel / architecture	Linux 6.17.0-1029-nvidia aarch64
ChatGPT package	26.901.31953
GNOME Shell	46.0-0ubuntu6~24.04.14
libmutter-14-0:arm64	46.2-1ubuntu0.24.04.16
GNOME Remote Desktop	46.3-0ubuntu1.2
Xwayland	2:23.2.6-1ubuntu0.8
NVIDIA driver	580.173.02
Session type	wayland

What issue are you seeing?

Launching the newly installed ChatGPT application from the GNOME application launcher repeatedly disconnected the RDP session. Investigation found that GNOME Shell itself crashed, rather than only the ChatGPT window closing.

Before the workaround, the desktop account was absent from the video and render entries in /etc/group. Both groups were present with no listed members.

After adding the desktop account to both groups, verifying the configured memberships, and advising a full logout/login to refresh session permissions, the user confirmed that ChatGPT launched successfully. A subsequent check found the application running over RDP and both groups present in the active session's id -nG output. The exact logout/reboot sequence between the change and the first successful launch was not recorded.

Relevant evidence from the failing session

Observed on September 4, 2026, with local journal timestamps:

15:33:59  GNOME Shell crashed with signal 11
15:34:00  GPU process launch failed: error_code=1002
15:34:00  FATAL:content/browser/gpu/gpu_data_manager_impl_private.cc:417
           GPU process isn't usable. Goodbye.

The GPU launch-failure message occurred repeatedly. Xwayland messages around the failing sessions also included:

Failed to initialize glamor, falling back to sw
(EE) failed to write to Xwayland fd: Broken pipe
(EE) could not connect to wayland server

Apport reports were present for both /usr/bin/gnome-shell and /usr/lib/chatgpt/ChatGPT, with file modification times around 15:33. The GNOME report header recorded Architecture: arm64 and Date: Fri Sep 4 15:32:55 2026, consistent with an earlier launch failure during the same investigation.

These are selected observations, not a complete interleaved journal or symbolized backtrace. In particular, the quoted ChatGPT fatal GPU message follows the GNOME crash and may be a consequence of losing the display server.

What steps can reproduce the bug?

This is the observed reproduction sequence on one affected machine:

1. Connect to the DGX Spark's Ubuntu GNOME desktop using Windows Remote Desktop.
2. Use a desktop account that is not listed in the local video or render groups.
3. Install the official ARM64 .deb package.
4. Launch ChatGPT from the GNOME application launcher.
5. Observe the RDP session disconnect; reconnecting and launching again produced the same symptom.
6. Inspect the GNOME journal and Apport reports for the errors above.

Group absence alone is not a portable reproducer: device permissions, ACLs, session handling, and driver versions can differ. We have not reproduced this on a clean image or intentionally removed the working memberships to force another crash.

What is the expected behavior?

ChatGPT should launch while the remote desktop remains connected. If the session cannot access a required graphics device, an actionable diagnostic or supported fallback would be preferable to a desktop-session failure.

Additional information

Workaround verified on this machine

Run on the affected Linux machine as the desktop user, with administrator approval to grant that account device access:

sudo usermod -aG video,render "$(id -un)"
id -nG "$(id -un)"

The second command checks the account's configured memberships. Fully log out of the Ubuntu desktop and log in again so existing processes are replaced; merely disconnecting RDP may leave the same session alive. If the session still has stale memberships, a reboot may be necessary.

In the new desktop session, check the effective memberships:

id -nG

Then launch ChatGPT normally. Both memberships were added together in our test, so we have not established whether one group alone would have been sufficient.

The applied remediation did not change ChatGPT launch flags, replace the ARM64 package, disable its sandbox, or change graphics drivers. The same ChatGPT package version is running successfully afterward.

Interpretation and requested follow-up

The evidence supports a graphics-access/session interaction and a successful group-membership workaround. It does not establish the precise defect in ChatGPT, Chromium, Mutter, Xwayland, or the NVIDIA driver. The device access denial and crashing stack were not captured, and group membership is only one way Linux can grant device access.

Please consider documenting this DGX Spark/RDP troubleshooting case in the Linux installation guide and investigating graphics initialization under a remote session with restricted device access. Any preflight diagnostic should test effective access rather than assume every Linux user must belong to these groups. Please route the underlying compositor issue upstream if appropriate.

A closely matching, independently reported DGX Spark problem affected VS Code and LibreOffice over Windows RDP; adding video and render memberships was also reported to resolve it: NVIDIA forum report.

The official Linux app guide confirms ARM64 Ubuntu packages and documents Xwayland as the default compatibility path when available. Native Wayland and disabled-GPU launch modes were not tested here.

We searched this tracker for DGX, Linux RDP, GNOME crashes, and video/render group reports and did not find the same reported combination. Full crash dumps, host addresses, account names, and unrelated logs are omitted.

Start with the Linux app guide and the reported launch path at /usr/lib/chatgpt/ChatGPT, then review the GNOME Shell and ChatGPT Apport reports alongside the journal errors. Compare effective video/render memberships before and after the workaround, without assuming they prove the root cause. Done means establishing a reproducible cause or documenting a supported diagnostic or fallback for restricted graphics access over RDP.