Unofficial ChatGPT / Codex desktop Flatpak

General
1

First, the honest framing: if you just want ChatGPT on Bluefin, use the cask. One command, updates itself, nothing to configure.

brew install --cask ublue-os/experimental-tap/chatgpt-linux

That unpacks OpenAI’s rpm into ~/.local and runs it as you. For most people that is the right answer, and my original post implied a distribution gap that doesn’t exist here. That was wrong.

This is for the smaller group who want the opposite trade. Codex executes code. I don’t want the thing running commands holding read access to ~/.ssh, ~/.aws, my browser profiles and my work repos.

flatpak remote-add --user chatgpt https://rulin132.github.io/codex-flatpak/chatgpt.flatpakrepo
flatpak install --user chatgpt io.github.rulin132.ChatGPT

It starts with no filesystem access at all. You hand it directories one at a time:

flatpak override --user --filesystem=~/Projects io.github.rulin132.ChatGPT

Renderers stay under zypak rather than --no-sandbox, which is what the other Flatpak repackagings use. No OpenAI binaries are redistributed: it uses extra-data, so your machine fetches their .deb against a pinned sha256. x86_64 and aarch64, signed, built in CI.

You can go further and deny X11 outright:

flatpak override --user --nosocket=x11 --nosocket=fallback-x11 io.github.rulin132.ChatGPT

What you give up: the desktop pet doesn’t render. Upstream draws it in a transparent window and this Electron build doesn’t composite that on Wayland.

Source: GitHub - rulin132/codex-flatpak: Unofficial Flatpak of OpenAI's ChatGPT / Codex desktop app. Sandboxed, redistributes no vendor binaries. · GitHub

Happy to answer anything about the packaging, bug reports and PR’s are welcome.

2

I’m unsure why we need to do any of this:

brew install --cask ublue-os/experimental-tap/chatgpt-linux

3

Fair question. The cask unpacks the rpm into ~/.local and runs the binary on the host, so ChatGPT can read everything you can: ~/.ssh, ~/.aws, your browser profiles, your work repos. To be fair, Chromium’s own renderer sandbox still applies there; it is the app process itself that is unconfined.

The Flatpak starts with no filesystem access at all, and you hand it directories one at a time:

flatpak override --user --filesystem=~/Projects io.github.rulin132.ChatGPT

So, different trade-off rather than a duplicate. If you want it on PATH and integrated with the host, the cask is the better fit. If you want it boxed in, this is.

Unrelated, but your livecheck URL pointed me at upstream’s APT index, which publishes Version, Size and SHA256 directly. I had been downloading 750 MB of debs every night to compute those myself. So, thanks for that and I may look into improving the way it handles this part.

If you do not care about the pet, you can go further. The only reason to grant X11 is that overlay, so deny it outright rather than just not granting it:

flatpak override --user --nosocket=x11 --nosocket=fallback-x11 io.github.rulin132.ChatGPT

Now it is Wayland-only and cannot reach an X server even if one is running. That closes off X11’s shared-server model, where any client can read other clients’ input and window contents.

4

This isn’t a criticism I’m just saying if we need to get codex let’s do it the most efficient way possible.

I had been downloading 750 MB of debs every night to compute those myself.

You are using decades old linux distribution tools that do not work for modern workflows. These tools were not designed for modern software and just break everything. Why is X11 even part of this equation?

It’s going to suck. We can just use the state of the art without dealing with this crap.

5

Apologies, after re-reading I opened by saying deb-and-rpm-only is “not much use here”, which isn’t true, didn’t know cask was an option too. In general, availability was never the gap I actually fill. The gap is confinement, I don’t want the thing that executes code holding read access to my whole home directory. I should have led with that instead.

On X11 you’re right, and it’s my own doing. I offered XWayland as the workaround for the pet overlay not compositing on Wayland, which is reaching for exactly the stack you’re saying should stay dead. The better guidance is not to reach for it at all: deny X11 outright and accept that the pet doesn’t draw.

flatpak override --user --nosocket=x11 --nosocket=fallback-x11 io.github.rulin132.ChatGPT

So the cask should be the default for Bluefin. Mine is for people who want it boxed in, which is a smaller group, and that’s fine.