ctmnt

Man I miss Tracker.

I agree / hope that’s what they meant. It seems disingenuous, though, to describe it as unreadable, since obviously something has to read it to bake it into the deploy. And given their apparent lack of effective security boundaries in one area, why should we assume that they’ve got the deploy system adequately locked down?

It’s not like I had a ton of trust in them before, but now they’ve lost almost all credibility.

Where did you see that a Context employee had credentials stolen in February? I haven't run into that particular data point.

Not just into Vercel's env vars, but into Vercel's customer's env vars.

An email from Vercel came to my company at 10:47am UTC. It contained little information, and said:

At this time, we do not have reason to believe that your Vercel credentials or personal data have been compromised.

Which is not very reassuring without actual information, since presumably they would have said the same thing on Saturday, if asked.

They mean the latter. Very unclear how that translates to meaningful security.

You’re right, I should have been more careful in my reference to AWS. No need to be snarky about it.

Let me rephrase: aside from that one example from a couple years ago, I haven’t seen any examples of production code written in Lean. I’d be very interested in being proven wrong, this isn’t something I desire, just what I’ve observed. Have you seen any others?

More generally, you implicitly make a good point: writing important libraries in Lean and calling in from another language is probably the most likely use case. So not programs / apps / binaries written in Lean, but small critical components.

You’re right, there is that one example. Feels like we’re in exception that proves the rule territory. But I’d be very interested in being proven wrong! This isn’t a desire of mine, just what I’ve seen. Do you have other examples?

Also, part of my confidence comes from both having been a professional programmer for decades, across many languages, and also having programmed in Lean. It’s a great language for math, perhaps the best choice right now. But as a general purpose language it’s incredibly quirky.

That is amazing. Compounded by the fact that there's a product listed as "COMING SOON JULY 2025"! This isn't an abandoned site.

Sure, but are you worried about someone cheating on their arXiv submission by exploiting a buffer overflow? It’s a real bug, it’s just not very important.

There are no Lean applications other than Lean. This is an important point most of the comments are missing. Lean is for proving math. Yes, you can use it for other things; but no, no one is.

Still good to have found, but drawing conclusions past “someone could cheat at proving the continuum hypothesis” isn’t really warranted.

Hi Kiran, thanks for following up. FWIW, I enjoy your blog and your work. And I do think it was a valuable bug you found; also nice to see how quickly Henrik fixed it.

Say more about people running Lean in production. I haven’t run into any. I know of examples of people using Lean to help verify other code (Cedar and Aeneas being the most prominent examples), but not the actual runtime being employed.

I took a quick scan of lean-lang.org just now, and, other than the two examples I mentioned, didn’t see a single reference to anything other than proving math.

I’m sure you’re in the Lean Zulup, based on what you’ve been up to. Are you seeing people talk about anything other than math? I’m not, but maybe I’m missing it.

Yes, it isn’t performant. Lean isn’t a language for writing software, though you technically can; it’s a language for proving math.

This article’s framing and title are odd. The author, in fact, found no bugs or errors in the proven code. She says so at the end of the article:

The two bugs that were found both sat outside the boundary of what the proofs cover. The denial-of-service was a missing specification. The heap overflow was a deeper issue in the trusted computing base, the C++ runtime that the entire proof edifice assumes is correct.

Still an interesting and useful result to find a bug in the Lean runtime, but I’d argue that doesn’t justify the title. Or the claim that “the entire proof edifice” is somehow shaky.

It’s important to note that this is the Lean runtime that has a bug, not the Lean kernel, which is the part that actually does the verification (aka proving). [1] So it’s not even immediately clear what this bug would really apply to, since obviously no one’s running any compiled Lean code in any kind of production hot path.

[1] https://lean-lang.org/doc/reference/latest/Elaboration-and-C...

This looks cool enough, but it’s starting to drive me crazy how people are in such a rush to put out their macOS apps they can’t be bothered to get a developer account and run a one line command. It’s not hard.

I used to be sympathetic to complaints about not wanting to pay the developer account fee. But when you’re vibe coding, you’re probably paying a good chunk of change to your LLM supplier of choice every month, and the yearly developer account fee seems minor in comparison

Also, it’s just such a bad security precedent. This page describes the error you get as “the typical macOS Gatekeeper warning”, as though it were just another piece of corporate silliness, like clicking through a EULA.

I find both to be true. I use Claude for most of the implementation, and Codex always catches mistakes. Always. But both of them benefit from being asked if they’re sure they did everything.

To be clear, for those reading these comments and thinking “oh no Azure”, this is an addition to the list of cloud companies that provide “cloud infrastructure worldwide” for “all products”. Alongside GCP and AWS. This is not a GitHub style announcement that they’ve moved all operations to Azure.

Ah, my mistake! Thanks for the correction.

But I believe you can replace versions on both, nonetheless. It’s a multi step process, unpublish then publish again. But the net effect is the same.

They absolutely do. In this case litellm 1.82.8 had been out for at least a week (can’t recall the exact date offhand). The compromised version was a replacement.

This is fantastic, thank you. Your reporting has been great. But also, damn, the playlist.

I get the email notifications from Anthropic’s status monitor, and I think they might be my most frequent emailer these days.

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

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.

I can’t tell if you’re joking or not, but it’s funny either way.

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.

Lol. You win.

Good point on vibing though.

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!

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?