Updater direction: how conservative should we be?

[ilysenko]

Before changing the updater model, it is worth pausing and agreeing on the direction.

Right now this project downloads the official OpenAI Codex Desktop DMG on the user machine and adapts it locally for Linux. This is slower and more complex than installing a ready-made Linux package, but it avoids this repository directly distributing the OpenAI desktop app/resources.

The main concern is redistribution risk. If Linux packages published by this repository bundle the OpenAI Codex Desktop app/resources, OpenAI could reasonably see the project as redistributing their product. That could put the whole repo at risk.

OpenAI will probably ship an official Linux Codex Desktop eventually. Even then, this project can still have a place: Linux-specific packaging, desktop integration, optional features, native helpers, experiments, and things that may not exist in the official app. That is another reason to keep the project on safe ground and avoid shipping OpenAI app files ourselves.

The project is shaped by everyone contributing here, and the ideas/work are appreciated.

Options

What updater direction should we take?

1. Keep it simple and conservative: continue local rebuilds from the official OpenAI DMG, and only improve reliability/performance.
2. Keep local rebuilds from the official OpenAI DMG, but add better updater UX such as feature selection before rebuild.
3. Publish only our own Linux tooling/bootstrap packages; those packages still download the official DMG on each user machine.
4. Explore a separate Linux-native wrapper/client long-term, without bundling OpenAI desktop app resources.
5. Other direction: explain in the comments.

Please vote by commenting with the option number, or explain a different direction below.

[avifenesh]

My take: OpenAI will probably ship official Codex Desktop support for Linux eventually. I’m already on the waitlist too. But we don’t know when it will happen, what it will include, or whether it will solve the Linux-specific problems this community is dealing with now.

I agree we should keep the main repo safe. We should not redistribute OpenAI app resources directly. The current model — download the official DMG on the user machine, adapt locally, and improve reliability/UX—is the conservative path and should remain supported.

But I think there is room for a separate beta direction: a Linux-native wrapper/client/tooling layer that still uses Codex but provides our UI, updater UX, conversation features, native helpers, and Linux-specific integration. It should be isolated from main, and it should not bundle OpenAI desktop resources.

The features we might implement are not really “stealing” ideas. Things like conversation mode, better updater UX, native app performance, and desktop integration are common product patterns across Codex, Claude, Perplexity, and similar tools. The important line is that we implement our code and do not ship OpenAI’s product files.

When official Linux support arrives, we can compare both paths. Maybe the official app is better and we stop investing in the beta. Perhaps our beta is better for Linux users and we decide to keep it. Possibly we keep both for different users. This should be a two-way-door decision, not something that blocks the current project or forces us into one path too early.

So I would suggest:

1. Keep the current main path conservative:

• Continue local rebuilds from the official DMG;
  • improve reliability, performance, and updater UX;
• Do not bundle OpenAI app resources.

2. Open a separate beta/side branch:

   • Linux-native wrapper/client experiments;
   • our code only;

• Optional community-driven features;
  • no impact on main unless the direction proves useful;
• People from the community who are interested can join, test, and help maintain it.

I already started a small Rust POC just to see what is possible. It is incomplete, but it looks promising. If you are okay with the direction, I can open it as a beta branch and people who care about this path can join the effort. Then we can run both approaches side by side, learn what works, and decide based on actual usage instead of guessing.

[moxw]

I agree with this take.

[avifenesh]

And i would pin this and link with an issue to it.

[ilysenko]

@Leay15 @avifenesh pls check invite and take a look https://github.com/ilysenko/codex-desktop-linux/wiki/Maintainer-Notes

[avifenesh]

@ilysenko I pinned it, created a locked issue that points to the discussion and created it for this kind of community question.

[PinguuSS]

My vote is option 2

The important distinction for me is separating the thing we maintain from the thing we transform. This repo can safely own the Linux packaging, updater logic, setup UX, feature manifests, diagnostics, and native helpers, and the codex desktop payload itself should stay something resolved on the user’s machine from the official source.

that still leaves plenty of room to make updates feel much better, such as feature-aware rebuilds, clearer progress, better recovery, and maybe tooling-only release assets later, i would just avoid making public release packages the delivery channel for openai own files. For the native-wrapper idea, sounds nice, as long as it is a separate experiment with its own boundaries

[joshyorko]

maybe openai picks thsi up we all get rich and buy boats who knows, best not to piss them off, so im total agreement with you

[PinguuSS]

Maybe 😂

[joshyorko]

Option 2, im swtich to my locall brew builds as well given this discussion thread, and not publishing

[Leay15]

My take:

I feel like we could go with a mix of options 2 and 3. Option 2 would improve the UX, while option 3 would give us the ability to install the tools directly from a repo and, with that, ensure that all users always have access to a stable version of the tools.

I like the idea of having our own UI, but I'm not sure how much time we can realistically dedicate to maintaining it, or whether it might eventually become obsolete because of OpenAI's own version. At one point I also thought about it as a way to avoid using Electron and move to Tauri, but that was just an idea.

[avifenesh]

not so far

[joshyorko]

i mean if we are building a new ui might as well give up and bow down to t3codes i mean that is not the point right, the point is to package this thing for linux or am i off . Codex Desktop Slaps hard becasue it is Codex Desktop not becasue some people decided to try and reinvent their whell, There are 100 other opeole doing that , this could be the factory for every linux distrobution and or immutable distro. but i don't know i just wanted to have codex desktop on my Bluefin Fedora bootc image so i found this and was like hell yeah.

[joshyorko]

and also i have not wasted the last 5 days of my life to come this far, we didn't come this far to come this far is my point.

so lets not get sued, lets not build another web service here, lets build it as is and add cool things like a web server for it like on my self-hosted branch, but not reinvent the UX , I like the UX

[avifenesh]

@joshyorko I actually want to mimic the UI exactly, its just first one shot, and I've now found a way to not reinvent the look but directly translate, so it might work better.
It's simply that Electron is a fallback that we use but it is super heavy and slow, it leaks resources, and sometimes leaves hungry ghosts in the background, so I actually would like to replace Electron with native code written in pure Rust that looks and feels the same. And let us introduce new features constantly.
Anyway, that's for sure not going to be the main branch, im just writing stuff. Usually they are not really being used at the end. So that's just an image for now, its not threatening.

[PinguuSS]

Off-topic; you guys should create a discord server or something like that, it would be nice to communicate, announce things, and get in touch with the community. @ilysenko @avifenesh

[avifenesh]

Thats on @ilysenko