I'm a Codex user, and when it was still a standalone app it worked really well for me. Since it became part of the new ChatGPT app, the app feels noticeably slower and, at least on my machine, is currently using around 1.27 GB of RAM [1].

The old ChatGPT app, which has now been renamed "ChatGPT Classic", feels much faster and is using around 478 MB under the same conditions.

I have a reasonably powerful PC, so the difference is pretty noticeable. I assume Classic will eventually be discontinued, but so far the transition to the new app on Windows hasn't been particularly good for me.

[1] https://imgur.com/a/nQkneGL

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 ?

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?

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.

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.

- 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.

[1] https://rubymamistvalove.com/block-editor

Download Edge for Linux and use the PWA. It's still crap but at least it kind of works mostly.

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.

Product releases at large companies are slowed dow by coordination and resources more than actual development. (I'm an Electron maintainer who is currently working on better Linux support in the framework, and also a developer/PM for a commercial app that supports Linux.)

It's very likely that the Codex Electron app already "worked" on Linux back in February, as in someone internally could build and run it from source and start a chat session. That fact would have made it possible for a small team to make a business case and start getting support from ops, QA, CS, marketing, legal, etc. The engineers would spend their unlimited tokens on Linux-specific build, packaging, and platform integrations (remember this is a computer use agent) to take the app from a prototype to something a company could actually launch and support for millions of users.

Apps are also a moving target. The entire time building up to release, the Linux desktop app would have been getting feature and design updates for free from the updates going out on Mac/Windows/web. None of those other teams working on those features have have had the time (or the mandate) to coordinate with Linux engineers if they were building a separate app from scratch, and I suspect such a proposal would never have gotten off the ground.

I think you've summarised it really well, & it shows:

- the revolutionary promises of AI-driven rapid delivery is nonsense when the delivery bottleneck was always elsewhere - AI is speeding up the part that was never slow

- the fact that - as you point out - it was likely working in Feb but needed a business case gives a good impression of the leadership's approach to Linux support: it's likely such internal case-making will continue to be a factor in future Linux build maintained

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?

Linux users are kind of averse to trojans. You should call it Back Orifice For Linux. You don't even have to change the OpenAI logo!

These apps stands as last defense between users and legitimate owners of compute resources that is electron and pals.

Surely they can just vibe is down to a reasonable footprint, right? Right?

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.

Give it a full desktop in a VM if you want to, just not direct access to your system.

It created 2 new users and then assigned new NTFS permissions for every single file under my user directory to them. This of course wrecked havoc, ssh refused to work, several applications refusing to start and a ton of permission errors. It did this without even a warning in the background and it also does not undo any of it when you uninstall it.

It took around 3 hours to fix it by updating ~10 million NTFS permissions for every single file under my user directory.

I’ve been using Codex in full access mode constantly for the past couple months on a Pro plan and I haven’t had a single incident like this. I’ve used it across macOS, Linux, and Windows as well, so my usage isn’t limited to a specific setup either.

https://medium.com/conquering-corporate-america/10-tricks-to...

For instance recently, media downloads on my NAS became quite a bit slower. I asked it to investigate and it quickly got back to me saying the issue was the ethernet link had been downgraded to 100Mbps from 1Gbps. It even went through journalctl to tell me when this had happened. To fix it I just had to plug an ethernet cable out and back in. Now this is the kind of thing, earlier I would have to spend an evening on. But given an open system like Linux, a well made safe model just makes it so much more accessible than having to RTFM for one off things I am sure to forget in a month.

I dont really let it run loose through my systems, and keep an eye on the thinking traces it puts out and the permissions it asks for. But now I dont have to slog through manuals and deal with gruff people on the internet. I can choose to do so after the fact, depending on how much free time and curiosity I have.

It’s a prison of your own making.

I’ve personally adopted a process where I structure my projects to ALWAYS keep credentials and sensitive information in a separate directory.

The working copy gets rsynced to and from a dedicated VM with whatever $HARNESS.

And for your hypothetical client.

Especially as judging by your description they despite this allow any VSCode plugin to be installed alongside it.

> and I am not making my life miserable to work with editors lacking the specific tools

And that’s the self-imposed prison I was talking about, there’s always alternative tools. In my mind a specific tool is something like Ghidra.

Sectors involved in, in no particular order: government, financial, telecom, energy (gas and electric), manufacturing (large european conglomerates), healthcare, logistics

In fact I was the one usually helping IT Teams put the torture devices and policies you’re subjected to in place lol.

Banks would usually give us laptops with smart card readers and only allowed access to their VPN from a limited set of public IP addresses.

Govt was a bit more lax, but same principles applied, was really fun doing any kind of work over a laggy VNC.

My favourite one was probably where you’d have to hop from one Azure cloud VM, to Citrix to a bastion windows box, off of which you’d RDP to the actual work VM only to putty to the actual damn Linux box you cared about.

Energy sector was more lax, they let us set up a GitLab instance and a small CICD setup to which we’d push the code developed on our local boxes.

Oh and the ones I mentioned - they usually ask us what tools we wanted on our boxes as well.

Weak argument. People don't have infinite time. People just want tools they trust and that aren't enshitified.

In fact, VSCode’s support for Lean is via LSP anyways.

Manual tool calls. I ask AI to give me all the necessary reconnaissance commands, then I run them myself on the host and paste the output on the terminal with the SSH connection into the guest virtual machine where the harness is running. The AI then either figures it out and gives me the answer or runs additional tool calls by me. Repeat until annoying task is done, interrupt if anything suspicious shows up at any point.

If you can’t make that judgement call because of lack of knowledge/familiarity it’s okay - spawn a new fresh chat, get up to speed on the topic first and then resume.

That way you accomplish three things: you learn something new, you fix your problem and you don’t let a Trojan do whatever the hell it wants to your box which among other thing contains all the browser sessions and cookies :)

Also note, that RAG and even vector search are more paths of the early days that didn't prove too valuable. Just let your agent search it directly and optionally create an index as a default entrypoint for common topics.

I guess OpenBSD is the only OS where I never had any problem with Bluetooth audio.

So, yes, I would say agents are pretty good at working with Bluetooth on Linux

- I inspect the agent's changes, and only apply them - at once - if they are OK. So I have no half applied bad changes to my system, and I can catch critical mistakes before they are applied.

- I can roll back the changes by just doing a `git revert` and reapplying

- The agent cannot read secrets or unrelated data, just config.

- The agent gets the full configuration of all systems at once, without having to maintain parallel documentation (which can get out of sync) or rediscover each time from scratch (access my running systems, for example with `ssh root@server`).

- It's harder for the agent to miss some aspect of the configuration, because it's all in my dotfiles. If it's not there, it's nowhere

Also in the news: https://www.whitehouse.gov/presidential-actions/2026/08/expa...

    "The American private sector is the most innovative and
    technologically advanced in the world, and its scale,
    speed, and capacity secure a critical offensive cyber
    advantage for the United States."

Since we now have three "Codex"es, I think it's worth specifying you're talking about codex-cli/tui. Codex the hosted version and Codex the GUI are both fully proprietary I think (besides the codex-cli/tui parts they use, I'm guessing mainly the app-server stuff).

Or we are just assuming that was a PR stunt, which it almost certainly was.

Either way, this shit isn’t getting near my system.

No.

> Or we are just assuming that was a PR stunt, which it almost certainly was.

It wasn't.

> Either way, this shit isn’t getting near my system.

Sounds about right.

> It wasn't.

Prove it. But you can’t, which is problematic for you.

Nobody should believe anything OpenAI says about anything. They either lied about it breaking out of a sand box, or they’re incompetent by building a sandbox their AI could break out of.

It’s a cute story, though.

I think this cynicism is more then warranted. If anything HN is not cynical enough to meet the times we are in.

Experts related to real programming topics are gone or silent. AI experts have never even been here in the first place. It is all about Electron apps, prompts, agents and other bullshit.

HR is charmed by them despite their lack of discipline.

They use Linux because it's there. If Linux wasn't there, they'd use what's there. There is nothing about Linux that makes it unique enough to be make or break OpenAI. Not one thing.

And yes, when a company distributes their app for the Linux desktop, we should be grateful or at the very least not hostile.

The attitude of Linux zealots is honestly tiresome and it makes us all look bad.

One of the issues with this new trend of vibecoding a million features, is that the (vibecoded) docs are labrynths of new features, and features that are deprecated or redundant with 2 month younger features.

But I can’t tell from these docs if the ChatGPT desktop app needs to remain running on your macOS/Windows host as a proxy, or if you can directly SSH from your phone to your Linux box with just Codex CLI.

When I tried it a couple of months ago, the CLI version didn't have that feature, it's only present on the desktop app. The docs you linked seem to confirm this:

>In the ChatGPT mobile app, open Remote to work with ChatGPT or Codex chats on a connected Mac or Windows device.

>Start in the ChatGPT desktop app on the host you want to connect.

>Open the ChatGPT desktop app on the host. Go to Settings > Connections > Control this Mac or PC,

Then there's the SSH thing

>Use an SSH host or managed remote development environment when the project already lives in a remote environment. Connect the desktop app host to that environment first;

>For SSH setup details, see connect to an SSH host.

At this point I feel that I need to combine it with other experimental vibecoded features? And the end result would be something that I can hack together with some ddns reverse polling thing. I know I can download an ssh terminal to my phone and connect to my computer by either opening a port, or doing some wacky network stuff. I don't see the value add in doing that by adding the commands I would have to run to some openai config file yaml like

> ssh-tunnel: tailscale > port: 8411

instead of making a bash script with

> tailscale -p 8411

tl;dr: The feature is desktop app dependent, and the desktop app is now on linux, rejoice

- nicer diff rendering, and directly mentioning parts of a diff

- Latex rendering (pretty annoying in the CLI, you have to actively tell Codex it's running in a terminal and replace Latex syntax with UTF-8 glyphs)

All the stuff people are hacking into TUIs is honestly a bit silly, they're actually very inefficient for high fidelity UIs. Having worked in it and on it before while @ GOOG, the actual renderer in Chromium is an optimized thing of beauty. It really makes sense to leverage it. Appropriately.

But all of the above could (should) be done as a locally hosted web page via the existing codex CLI launching a local web server... rather than shipping an electron binary with its own entire fork of Chromium.

And I experimented with gpui from zed, that was even harder to work with.

Of course they could chase performance, but ultimately time to market is the #1 factor right now, and coding agents still aren't good enough to just immediately realize an entire GPUI app from scratch with nothing more than a figma design. Still requires a ton of oversight.

Why do you care? If I chose platform X over Z, that is potentially because I like the visual particularities of this platform.

Seems pretty solid for Mac, but idk about Windows and Linux.

https://openai.com/index/building-chatgpt-atlas/

When I tried that with the Codex CLI version on a Linux VM, I did not get it to work. Possibly because OpenAI only supports connecting ChatGPT to a desktop installation of Codex?

If you really only use ChatGPT on IOS and a VM and nothing else, then I would be curious how you set that up. I do not see a "connect to codex via ssh" in my ChatGPT app. I only see "Connect to a desktop".

Oh HOLY MOLY! Now I see there is not only a "Remote" section in the app but also a "Connection" section where you can add an ssh connection. I need to try that.

Thanks!

Also for future readers: Yes, I'm sure there's no desktop app in the middle. I have dedicated remote VMs that run agents. I don't have them running on the desktop, not even as a middle man.

Meanwhile I am looking at a Crush client running beside neovim in a herdr session I am accessing via ssh to a machine in my garage with 4 local GPUs. I think we Linux users have got this without Sams help.

This is fantastic as I can toast or reheat my frozen waffles on the same machine which is also running a agentic loop on codex desktop to cook my software.

Even with Linux, there are more people -- including many non software engineers -- that are installing Linux on their home computers and may be interested in this.

Bear in mind that HN users don't remotely resemble the general population, or even employees at a tech company -- there are lots of people in finance, business, legal etc who could potentially benefit from this.

There's probably more I don't remember too. In my opinion TUI apps are just silly. You don't get any of the advantages of it being just plain text because it's all wrapped in funny Unicode characters and at the same time the GUI capabilities are hamstrung by being text on a grid.

It can be controlled from your phone once paired, and it lets you actually see agents that it orchestrates in the threads. Also if you use MCP Apps, it can integrate those into threads.

Tabs for long-running often-compacted sessions is a difference I've noticed in emergent UX.

The best feeling has to be in the CLI, in my oppinion. A low-stakes project where you can let ultracode runaway from you in the CLI is the most fun.