Posted by allanrbo 13 hours ago
I previously really enjoyed the Codex app. It was easy for me to understand and find what I needed. The conversation view provided the right amount of information without feeling too concise or full of jargon and the typographic hierarchy made it easy to skim. The project based workflow made sense for my needs.
Ever since they combined all ChatGPT into one app though it has become a mess. It's trying to do too much in one. The settings menu is especially bloated, and I find the UI to be too complicated for the simple questions I'm asking outside of development work. I would rather just use the web interface for general use at this point. They've also been updating much of the UI to follow the same patterns as Claude, and I've not been impressed with the Claude desktop app.
To me, they are taking multiple steps backwards. I hope they eventually find their way again.
Surely they can just vibe is down to a reasonable footprint, right? Right?
These apps stands as last defense between users and legitimate owners of compute resources that is electron and pals.
https://community.openai.com/t/codex-in-chatgpt-desktop-app-...
"The desktop app is designed as a workspace for managing projects, working with files, using browser workflows, and running Codex alongside ChatGPT."
Not sure if I really understand this. And somehow I am worried about ChatGPT having access to my files and workflows. How much control do I have?
1. Much better multi-agent orchestration. The app supervises many agents, with different project views and built-in git worktrees, so agents can work on isolated copies of the same repo. It's easy to jump between tasks and see changes. I recall OpenAI wrote that CLI was not designed around this style of work.
2. The app combines multiple terminals, file previews, PR-review workflows, SSH connections, an integrated browser, and page annotations. For front-end stuff, Codex can run the app in Codex for mockups/prototypes, then iterate inside the app. IMHO I think this is a much faster, more intuitive flow.
3. For long-running and recurring agent workflows, I think they're much easier to manage in the app. You get automations, review queues, persistent conversation context, future schedules, and auto resume for longer running tasks. E.g. CI failure summaries, issue triage, and release briefs.
You can do some of the above, to some degree, with varying levels of success in the CLI, but I think it's miles ahead in the app.
This is mostly true with Codex and Claude Code Desktop, but gets a bit trickier with 3rd party tools.
I tried out some others and both Paseo and Kepler felt a little bit clunky especially around sub-agents and workflows (even if they let me have both OpenCode and Claude Code with different providers in the same UI). And OpenCode is plain lovely in the terminal but sorta okay in the browser: compare its display of sub-agents to what Claude Code does, for example; their tabbed interface also feels a tad less pleasant than the vertical menu of projects + sessions that most others are settling on, not their old look with icon per project, that was worse. There's definitely ample room for better tooling, then again early IDEs were far worse, so hopefully ADEs will get more polish eventually!
Still, regardless of what you use and across how many providers, it's nice to have everything in a single familiar interface, if you need that.
However, from the screenshots and description, I expect that you would have these advantages:
- History. Currently, if you type into the CLI (TUI) your intention and requests are captured in some transcripts, but not in conversational turns. If you want the history of what you typed into the cli/tui you would have to datamine it from transcripts. By contrast, on the screenshots you can see it is a simple conversation that's saved and easy to return to.
- Multiplatform. As per the announcement "Use Codex across ChatGPT, your editor, and the terminal", meaning that you could open the ChatGPT app on your phone and continue to interact with this. While this might not matter to you if you exclusively code while sitting in front of your computer, still, it helps you be able to stay on top of things if you are on mobile.
- Background tasks and autonomous work. It says you can schedule it to do things in the background (issue triage, alert monitoring). At the moment, it would only do this if you've asked either codex or another agent to build a harness for it that does so. (i.e. you could ask Claude to build a harness that calls Codex on some schedule or interval.)
These all seem pretty good and I look forward to starting to use it once it's been more battle-tested.
[1] notably, on the Anthropic side the Opus 5 regressions - I had to downgrade to Opus 4.8 as I found Opus 5 was unreliable. I currently use Opus 4.8 and Codex Sol 5.6.
With the recent security related events we already see that it seems to be wide spread practice that many operators avoid the hassle of isolating their agents.
It is just an incredible cultural experience to see how quick stupidity gets accepted as a behavioural default.
Even for developers working on Linux, you'll be surprised how many have never run a docker command in their life.
Or the long process to educate Windows users, and developers as well, to not run as Administrator.
A VM would be even better, but people could presumably run this in one if we manage to convince them of higher sandboxing in general ?
If you need the sandboxing capabilities provided by the application and don’t want to run it on the host, you should set up a VM, not a container.
From a systems perspective, it’s foolish to rely on a proprietary application to provide its own isolation guarantees. This is an OS-layer responsibility.
ML/AI experts suffer badly from hubris. They are brilliant in one domain. It transfers poorly to systems engineering. The proof is in the FelonyBench results.
Why would you even use bubblewrap once it's running in a container? I've been running Codex in a container since it was publicly available, not even sure what you'd use bubblewrap for when you already separated codex from the rest of your filesystem?
I think neither the bundled bubblewrap nor the Ubuntu 24.04 bubblewrap works properly under Docker with the default options ... Yes, I've just tested that by asking Codex to "Test that bubblewrap is working properly" and then "Test again" after apt-get install bubblewrap.
EDIT: So the solution is to run "codex --dangerously-bypass-approvals-and-sandbox" in a Docker container?
- Electron based app: Electron is a framework sold on the basis of enabling rapid cross-platform development at the cost of performance.
- Frontier AI company: AI is sold on the basis of enabling rapid development
- App was released in February & took 6 entire months to port to Linux
Though as someone who shipped commercial software on Linux, it wasn't that bad, you just had to ship everything other than the kernel.
Well, with RAM being so cheap, why bother trying to trying to be memory efficient? It's not like OpenAI has an infinite pool of "AI" software engineers to work on this...
Oh wait...
- Apple: SwiftUI/AppKit
- Android: Jetpack
- Windows + Linux: Avalonia (C#)
Avalonia seems good so far. I couldn't do Qt because I can't deal with that qBittorrent look. GTK is aesthetically pleasing for me, but it only runs on Linux. Avalonia lets me target both of these UI-toolkit-less platforms with something native-ish. Flutter is probably good too, but I am using uniffi-rs and that doesn't generate Dart bindings AFAIK.
Would love to hear other options.
Don't they have agent swarms with infinite tokens?
That was after I asked it to only touch 3 text files in its working directory, after which it sparked macOS permission prompts to access my Desktop, Documents, Downloads, and other apps' data. Thank god for the web platform and web apps.
They can be amazing. But you can write shitty code in them like anywhere else.
AIUI the reason is, "we", collectively even though we don't all work on them, optimize browsers for speed above almost all else. Then, when all the advertising websites on the internet consume all that speed, we can't go back and have to optimized for speed even harder. All that optimizing for speed ends up consuming lots of RAM, from all the images, the speed-optimize DOM with lots of cross-linking, the JIT and its generation of native code paths, the endless layers of caches, etc. etc. at every point where a browser can choose between RAM and speed it will choose speed unless it's just impossible to choose it for some reason.
So even if you write good code in Electron, it still tends to eat resources like candy.
On the plus side, if you write good code, you will pick up all those optimizations too, which is not necessarily all bad. Running something like VSCode at all is a powerful testament to the browser ecosystem now. IDEs do a lot of very heavy duty lifting and need a lot of performance to do all their work. But you can imagine that when the same text rendering system that enables all that fancy & fast syntax highlighting and all the other decorations and features in the editor window is used to display a preview of a markdown file that said preview is probably going to eat way more RAM than your instincts may have guessed.
Not even a $1T dollar company wants to maintain a native Swift Mac app even though they have AI models to build native apps for every platform.
Maybe they thought Electron would save them tokens to build the feature once and it works everywhere rather than spending more tokens on building the same feature on 3 platforms.
What better way to showcase their tools capabilities than to deliver apps that are native, efficient, and integrate well with the host system? By compromising with Electron and making mediocre, bloated software they are signaling that they just aren't there yet.
It would be like Ford buying Hondas for their company cars. It might save them money but it sends the wrong message.
It definitely is a fraction of the work these days to maintain three different desktop apps + two different mobile apps + a web app. But it's still a lot more work than an Electron app that is merely tweaked between platforms.
But I wouldn't know first-hand.
1. generally done well by many different UI frameworks
2. generally done better by most popular native UI frameworks than what Electron provides
BUT - those UI frameworks are typically not (very) cross-platform. In that context, Electron provides one of the best unified text-rendering stories of cross-platform options. But definitely far from the best overall.
It is a marketing expense. We are talking about it. Surely the token cost was worthwhile on that basis alone. Students will likely get some usage out of it, too. But paying a human to do this port would have been an insane thing to do two years ago. I’d be surprised if they have more than 1000 MAUs for this client by the end of the year.
Reminder that the macOS app went from "this is fairly well made" to "it downloads multiple gigabytes of random things and doesn't follow any design conventions nor standards"
The Linux app will fail the same tests.