Codex desktop renderer SIGILL at explicit UD2 trap on Linux (26.908.40834)

Codex desktop renderer SIGILL at explicit UD2 trap on Linux (26.908.40834)

What version of the Codex App are you using?

Installed Arch package: openai-codex-desktop 26.908.40834-1 (package version, not read from the About dialog).
Executable: /usr/lib/chatgpt/ChatGPT.
ELF build ID: a94d775832150267c05abac22e82f73df4a27f15.

What subscription do you have?

Not collected during crash diagnosis.

What platform is your computer?

Omarchy 4.0.3 (Arch-based Linux), x86_64, kernel 7.2.3-arch1-3.
Renderer command line included --type=renderer, --ozone-platform=wayland, --renderer-client-id=5, and a Codex user-data directory.

What issue are you seeing?

A Codex desktop renderer (process name ChatGPT, PID 56213) terminated with SIGILL / ILL_ILLOPN on 2026-09-17 at 16:31:39 CST (UTC-06:00), or 22:31:39 UTC. systemd completed saving the core at 16:36:01 CST; that later time appears in the coredump listing.

Kernel diagnostic, with hostname omitted:

traps: ChatGPT[56213] trap invalid opcode ip:55e60ec90018 sp:7ffea23a6510 error:0 in ChatGPT[cc82018,55e605eff000+e110000]

GDB disassembly at the fault:

0x55e60ec90017: int3
0x55e60ec90018: ud2  <-- faulting instruction

The installed ELF contains the same trap sequence at ELF virtual addresses 0xcc83017 / 0xcc83018 (file offset of UD2: 0xcc82018). This suggests an internal fatal-error path, but the triggering condition is unknown; it is not a confirmed root-cause diagnosis.

What steps can reproduce the bug?

No reliable reproduction is available. A conversation was active shortly before the crash, but the exact user action and renderer workload at failure could not be established. This is the only retained core-dump record for this application on the machine. The failure has not been deliberately reproduced.

What is the expected behavior?

The renderer remains running during normal desktop use, or reports a recoverable error without terminating.

Additional information

• systemd marked the core as truncated (727.6 MB compressed).
• GDB identified 27 threads, but all backtraces stopped at unavailable stack memory. The crashing frame had no resolved function name. Full call stacks and the failed condition are unavailable.
• A Crashpad sidecar written at the crash time reported {"capture_kind":"crash","osarch":"x86_64","ptype":"renderer"}. No corresponding minidump was present in that pending directory during inspection.
• The available kernel journal showed no OOM kill. Memory measured after the event showed approximately 16 GiB available out of 30 GiB RAM and 58 GiB free swap. These later measurements do not exclude an application-internal allocation failure at crash time.
• The package was updated from 26.901.51231-1 to 26.908.40834-1 on September 13, four days before the crash; no causal connection to the update has been established.
• No evidence currently implicates Omarchy configuration or packaging.
• Data loss is unconfirmed. Unsaved renderer state could not be assessed.
• No raw core, session transcript, full application logs, hostname, or account identifiers are attached.

Could the build ID and ELF fault offset be symbolized to identify the fatal-error path, and advise what additional targeted diagnostics would help if this recurs?

Prepared and submitted with Codex assistance from local systemd, journal, GDB, and ELF evidence.

Start with the matching ELF build ID and fault offset 0xcc82018, using the installed ChatGPT binary and any available symbols to determine whether the UD2 belongs to a fatal-error path. Review the Crashpad pending directory and the truncated core evidence, then identify what additional logs, minidumps, or reproduction details would be needed if the renderer crashes again. Done means either locating the relevant path or documenting targeted diagnostics.