Codex in ChatGPT desktop app for Linux is now in preview

Linux users, this one’s for you!

ChatGPT desktop app for Linux is now available in preview, bringing ChatGPT, Work, and Codex together in one native desktop experience.

Currently supported:

• Ubuntu 24.04 LTS and 26.04 LTS
• Debian 13
• Fedora 43 and 44
• x64 and ARM64 architectures
• .deb and .rpm packages

The desktop app is designed as a workspace for managing projects, working with files, using browser workflows, and running Codex alongside ChatGPT.

Download now

You can learn more about the desktop experience in the official ChatGPT desktop app documentation.

Has anyone installed the Linux preview yet? Please use this topic to share your feedback and experience.

Why is the website set up to only allow you to see a download button for the OS you’re on in many places, while other places have a button for Windows and MacOS regardless. There is so much continuity errors on the site is super frustrating sometimes to navigate. Its not doing anyone favours to hide download options and its a little ironic this baby-method is used when youre literally talking about someone using a very powerful AI.

They are going to generally have enough IQ points to click their OS. As it stands i cannot download the linux version on windows and take it to my vm. I HAVE to do it via the vm first. Why is this arbitrary limitation implemented INCONSISTANTLY.

Welcome to the community @oli.vier

A comparison doesn’t exist as of writing this, but here’s some anecdotal information:

Hah! I had missed it, thanks!

So Tibo is saying it’s pretty much parity in terms of features

I installed the new Linux ChatGPT/Codex desktop app from the official x64 RPM and encountered a Japanese IME issue on Fedora KDE.

Environment

• Fedora 44 x86_64
• KDE Plasma / Wayland
• Fcitx 5
• Japanese input method
• Official ChatGPT/Codex Linux RPM

Issue

When ChatGPT is launched normally from the KDE application menu, I cannot switch to Japanese input inside the message composer.

Japanese input works normally in native KDE applications such as KWrite.

I have encountered a similar IME compatibility issue with another Chromium/Electron-based application, Obsidian, on the same Fedora/KDE/Wayland environment. In that case, I ultimately had to run Obsidian through XWayland to get Fcitx Japanese input working reliably.

Because of that, I initially suspected that ChatGPT might require the same XWayland workaround.

However, ChatGPT/Codex can be fixed without falling back to XWayland.

Wayland-native workaround

Launching ChatGPT with:

chatgpt \
  --enable-features=UseOzonePlatform \
  --ozone-platform=wayland \
  --enable-wayland-ime

immediately enables Japanese input in the message composer.

So, unlike the workaround I needed for Obsidian, ChatGPT can remain Wayland-native. It appears that explicitly enabling Wayland IME support is sufficient.

I then copied the ChatGPT .desktop file to:

~/.local/share/applications/

and changed its Exec= line to:

Exec=chatgpt --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-wayland-ime %U

After running:

kbuildsycoca6

I can now launch ChatGPT normally from the KDE application menu and switch to Japanese input successfully.

Summary

There seem to be recurring IME compatibility issues with some Chromium/Electron-style applications on Fedora + KDE Plasma + Wayland + Fcitx.

In this case, however, ChatGPT/Codex does not need an XWayland fallback. Enabling Wayland IME support explicitly is enough:

--enable-features=UseOzonePlatform
--ozone-platform=wayland
--enable-wayland-ime

This makes me wonder whether these options, particularly --enable-wayland-ime, could be enabled by default in the Linux desktop app where appropriate.

Since the Linux app has just entered preview, I wanted to share the reproduction details and confirmed Wayland-native workaround.

Are you really sure that after you change it like this, it will use Wayland? I changed it once before and used Btop, but it still showed up as x11.

The mainstream approach should be to automatically identify whether it is X11 or Wayland. I don’t understand why my system ( Fedora 44 GNOME), which is Wayland, is falling back to running on X11, and I have a 4K monitor, so the display is terrible.

Thanks — that is a good point.

In my case, the important part was that adding:

--enable-features=UseOzonePlatform \
--ozone-platform=wayland \
--enable-wayland-ime

made Fcitx Japanese input work without having to force XWayland.

To verify the actual backend, I would check the running process rather than rely only on the launcher configuration, for example:

ps -ef | grep -i '[c]hatgpt'

and look for --ozone-platform=wayland on the main/renderer processes.

So I agree that ideally the app should automatically detect the current session and use Wayland when running under Wayland, rather than silently falling back to X11.

Your Fedora 44 GNOME result is especially interesting because my environment is Fedora 44 + KDE Plasma + Wayland. It may be worth comparing GNOME and KDE behavior here.

Also, the 4K scaling issue is another good reason for the app to prefer native Wayland where possible.

Finally, the Linux version is here, great job, team!

Quick feedback though: the biggest friction for me is that, Codex CLI projects on the same machine DON’T show up in the Desktop app’s project list.

All my CLI sessions appear as standalone chats, even with working dir and git branch preserved.

And if I add the folder manually via Create project, the project stays empty. No conversations.

It’s actually worse than remoting into my work server from Windows, where everything just works as long as I point to the right path.

Am I missing something? Would love to see this improved. Thanks again!

GNOME is amazing! I restarted and it’s working now!

Once again, certain types of distributions are being favored over others! Distributions that don’t rely on these package formats (Arch Linux, NixOS, etc.) simply won’t be able to use it (without some workarounds)!

A flatpak (or an app image at worst) would have been so much smarter.