I think you’re confusing capital c Claude Code, the desktop Electron app, and lowercase c `claude`, the command line tool with an interactive TUI. They’re both TypeScript under the hood, but the latter is React + Ink rendered into the terminal.
The redraw glitches you’re referring to are actually signs of what I consider to be a pretty major feature, a reason to use `claude` instead of `codex` or `opencode`: `claude` doesn’t use the alternate screen, whereas the other two do. Meaning that it uses the standard screen buffer, meaning that your chat history is in the terminal (or multiplexer) scrollback. I much prefer that, and I totally get why they’ve put so much effort into getting it to work well.
In that context handling SIGWINCH has some issues and trickiness. Well worth the tradeoff, imo.
Codex is using its app server protocol to build a nice client/server separation that I enjoy on top of the predictable Rust performance.
You can run a codex instance on machine A and connect the TUI to it from machine B. The same open source core and protocol is shared between the Codex app, VS Code and Xcode.
I had a nasty slow claude code startup time at one point something like 8s, a clean install sorts it all out. Back up your mcp config and skills and you're good.
That's the same reason I don't like Opencode, but Codex doesn't use the alternate screen. I remember it did when it was very very new, but now it doesn't.
Ah nice, good to know. I hadn’t used codex in a while. I actually really like opencode and its ui, just wish it didn’t clear the screen on exit. It could at least redraw whatever was last in the chat, that would be better than nothing.
I’ve looked at that a bit. Roff and mandoc etc have specialized tagging that’s not easily representable in markdown. You’d wind up with a lot of boilerplate or special non-standard markup, which would undermine the point.
The LLMs are super good at doing that translation, though. They can write those formats no problem.
On one hand this is a neat idea. I've thought about how nice it would be to have a visual layout tool for text-based designs. The current offerings are slim. Of course, you could easily argue that if you need a visual tool for it, you've gone too far; even the most sophisticated TUIs are still extremely simple.
On the other hand, for this work as they describe, it needs to be a complete UI framework across a bunch of languages and built on top of a bunch of existing frameworks. That seems... ambitious. Building one UI framework for one language is plenty hard enough.
The opening sentence “Those who have never endured the relentless ringing of tinnitus can only dream of the torment” does not mean what they think it means. Unless this is a very niche kink.
That jumped out at me too the first time I ran into Helix making this joke, and I was also disappointed to find that they meant modern++.
That said, I’m not sure I agree with your assessment that it’s wrong, exactly. Postmodernism did indeed follow modernism and come into being as a reaction to modernism. So I think “postmodernism” has a naive and original sense of being “what follows modernism”. Decades (so many at this point!) of discourse have added layers to that and undermined it and generally made it more complex. But the underlying meaning of the term remains.
(If your instinct is to respond with arguments about how works not limited to late 20th century western culture can be nonetheless classified as postmodern, I hear you, but the fact that the term itself was only coined post modernism remains, and is all I’m pointing to.)
Personally, I get more hung up on people using “modern” to mean “new”. Then to use “postmodern” to mean “more new” while to my ears (eyes) it means “dated af” is even funnier and more jarring.
Helix, the first editor to not believe in grand narratives. Helix, the relativist editor. Helix, now updated with the latest from Foucault and Derrida!
>Postmodernism did indeed follow modernism and come into being as a reaction to modernism.
I definitely agree that, strictly speaking, postmodernism is a somewhat loose label for an eclectic set of ideas and expressions following modernism. My issue was not with the label being denotatively incorrect – that postmodernism implies a deliberate and retrospective relation to what is labeled "modern" – but rather that the term invokes a spirit that is utterly missing from the project.
There is no rejection of teleological narratives, and in fact by misapplying this term acts to reinforcing them. It doesn't meaningful critique the projects its in conversation with except in terms that reinforce the underlying assumptions that motivated their production. It critiques Vim in terms of codebase complexity and multiplexity, and these concepts are nothing if not deeply familiar. Even with regards to the concept of coding as the composition and production of language, Helix only looks to make that process more efficient, rather than examine how this process reproduces itself, or how intent is masked and produced through abstraction and reference to the work of other programmers/authors.
I am not saying that it should have done that. It is by all means a perfectly good editor. But a perfectly good editor does not a postmodern editor make.
If anything, one could argue that the process of vibecoding is more recognizably postmodern, especially as a strict rejection of the modernist belief system that produces that process of coding. Its nondeterminism rejects efficient, coherent processes. It requires one to reimagine production as its ends, rather than by beginning with conventional initialization rituals. Its discursive rather than dictatorial.
Not to say vibecoding is the end of coding or even the way "forward", just as to say postmodernism is not the teleological end to thought.
I don’t have an opinion on how they should handle the nested VMs probably, but I very much disagree that Seatbelt is better. Claude Code (aka `claude`) uses it, and it’s barely good for anything.
Out of curiosity, why are you running Cowork inside a VM in the first place? What does that get you that letting Cowork use its own VM wouldn’t?
I agree. It’s a neat idea and I’d be interested in seeing the details. A downloadable tarball is a lot better than nothing, but it still makes more work to evaluate a random project than I’m inclined to perform. It makes me assume the commit history is ugly in some way (being charitable and assuming the code itself isn’t). Hearing that it’s developed within a monorepo of unrelated projects and experiments isn’t inspiring either. Anyway, perhaps someone else will download the source and report back.
Edit: To be clear, I’m not saying any of those things are true, just that those are the first thoughts I have when someone says their source is open but makes it difficult to view. In this age in which it’s so trivial and commonplace to make source easily viewable.
One interesting change between the last statement and this one: In the last statement Dario said that this designation had “never before been applied to an American company”. In the latest one the phrase is “never before publicly applied to an American company”.
I’m not sure what you’re referring to. It’s not (typically, as far as we know) a secret designation. We know of other companies designated as supply chain risks: Huawei, ZTE, and Kapersky are the first ones that come to mind.
reply