Codex in ChatGPT desktop app for Linux is now in preview šŸ§

Codex
1

Linux users, this oneā€™s for you! :penguin:

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.

5

Thatā€™s fantastic! Do we have a feature sheet anywhere, to compare the Windows vs. Linux versions?

6

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.

image
image1048Ɨ625 65 KB

7

Yeah
But I think here is a download
https://persistent.oaistatic.com/codex-app-prod/linux/deb/latest/chatgpt_amd64.deb

9

Welcome to the community @oli.vier

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

10

Hah! I had missed it, thanks!

So Tibo is saying itā€™s pretty much parity in terms of features :wink:

11

Thatā€™s pretty standard stuff, tbh.

12

Its standard to be inconsistent about when and where you post separate downloads? :laughing:

13

Also seems to work in WSL Ubuntu 24.04 with WSLg in Windows :laughing:

14

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.

15

Thanks for confirming this with Japanese IME.
I reported the same issue earlier with Korean Fcitx5 on EndeavourOS + KDE Wayland, and --enable-wayland-ime fixes it for me as well.
So this seems reproducible across at least Korean and Japanese Fcitx5 input methods, not just a single distro/setup.

16

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.

17

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.

18

When being rapidly dragged, the pet frequently flickers and jumps around erratically.

19

How much RAM does it use? Thanks.

20

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

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.

image
image257Ɨ377 31.2 KB

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

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!:heart:

21

I use Handy for speech-to-text. In the current ChatGPT Linux preview under Hyprland/Wayland, virtual-keyboard input generated by wtype is interpreted incorrectly: transcribed text is entered as mostly numbers and symbols. wtype works correctly in other Wayland apps on the same system, including Ghostty and VS Code. Using ydotool via uinput instead works correctly in ChatGPT.

22

GNOME is amazing! I restarted and itā€™s working now! :smiley:

23

Really happy to hear that! Gonna try GNOME myself some day.

24

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.