Astral Has Been Acquired by OpenAI  🔗 **Source:** [Astral Has Been Acquired by OpenAI](https://share.snipd.com/episode/88a44f7e-fab9-4992-b9fe-639fcd11cdce) ## Highlights - **Astral Acquisition Shows Agents Are Eating Dev Tools** - Astral joining OpenAI signals developer tools gravitating into the coding agent stack. - Adam Stacoviak notes Astral's UV, Ruff, and TY moving from standalone tools into Codex shows agents will absorb linters and dev workflows. Transcript: Adam Stacoviak Astral has been acquired by OpenAI. This is a big one, y'all. Astral, the company behind UV, Ruff, and TY, says it has entered into an agreement to join OpenAI as part of the Codex team. And I think the reason why this hits so hard for me is that Astral is not some random AI startup getting acqui-hired. These are already some of the most important tools in modern Python development. So the obvious first question is, what happens to the tools? Astral says the open source work continues after the deal closes, and that matters a lot because UV and Ruff in particular are not side projects anymore. These are foundational pieces of a lot of Python workflows right now. If we zoom out, the bigger revelation is the center of gravity for developer tools keeps moving toward the coding agent stack. Astral started out making Python development dramatically faster, and now the same team is heading into Codex. That tells you where they think the highest leverage work is next. And if you're a Python developer, or honestly any developer paying attention to tools, this is one of those moments worth clocking. Because it suggests the future is not just better linters, better package managers, better type checkers, and separate things. ([Time 0:00:51](https://share.snipd.com/snip/905c515b-b742-46b1-801d-55c154c6b3bd)) - **AI Middleware Now A Supply Chain Attack Surface** - LightLLM compromise demonstrates AI middleware is now a critical supply-chain risk. - The attack used a malicious .pth file and stolen publishing tokens from an unpinned CI security scan, exposing API keys and dev machines. Transcript: Adam Stacoviak Light LLM compromised by a supply chain attack. Light LLM 1.82 was reported to include a malicious.pth file that could execute on Python startup and potentially steal secrets from machines that installed it. Attackers published a fake LightLM 1.82 release directly to PyPy outside LightLM's normal GitHub release flow. The current explanation for how it got there is the real story. LightLM says a publishing token was exposed through an unpinned Trivi security scan in CI. This was not just one bad package upload. It was a supply chain chain reaction, compromised security tooling, stolen published credentials, then poisoned releases pushed straight to PyPy. LightLM is not some random edge dependency, though. For a lot of teams, it sits right in the middle of their AI stack, writing model calls, living right next to API keys, cloud credentials, and internal config. And the.pth file is a nasty delivery mechanism because it can execute when Python starts before anybody even imports the library. So if you're out there and you install the affected versions, treat this as an incident, not an upgrade bug. Check where it ran, rotate anything exposed, and look at CI and developer machines first. ([Time 0:02:08](https://share.snipd.com/snip/2d842442-abd0-46be-a3af-0e948f7c62a2)) - **Respond Immediately If You Installed Compromised LightLLM** - Treat installing compromised LightLLM versions as an incident and respond immediately. - Adam advises checking where the package ran, rotate exposed credentials, and inspect CI and developer machines first. Transcript: Adam Stacoviak Attackers published a fake LightLM 1.82 release directly to PyPy outside LightLM's normal GitHub release flow. The current explanation for how it got there is the real story. LightLM says a publishing token was exposed through an unpinned Trivi security scan in CI. This was not just one bad package upload. It was a supply chain chain reaction, compromised security tooling, stolen published credentials, then poisoned releases pushed straight to PyPy. LightLM is not some random edge dependency, though. For a lot of teams, it sits right in the middle of their AI stack, writing model calls, living right next to API keys, cloud credentials, and internal config. And the.pth file is a nasty delivery mechanism because it can execute when Python starts before anybody even imports the library. So if you're out there and you install the affected versions, treat this as an incident, not an upgrade bug. Check where it ran, rotate anything exposed, and look at CI and developer machines first. ([Time 0:02:25](https://share.snipd.com/snip/45156282-bd08-457a-82fb-5d16eafc1f30)) - **OpenCode Popularity Reveals Who Controls Agent Workflows** - OpenCode's rise highlights the open agent race and vendor ecosystem control. - Adam points out OpenCode had to strip Anthropic references under legal pressure, showing model vendors still control default agent workflows. Transcript: Adam Stacoviak OpenCode blew up this week as the highest traction new coding agent launched on Hacker News. OpenCode is an open source attempt to build the full coding agent surface area, terminal, IDE, desktop, multi-session workflows, LSP support with bring your own model flexibility. The uncomfortable signal is in the timing. Right before OpenCode hit number one on Hacker News, the project had to strip Anthropic OAuth and Anthropic references after legal pressure. And if you've been on X lately, you've likely heard about the Claude OpenCode drama. This should tell us the open agent race is real, but it's still happening inside ecosystems controlled by model vendors. So my read on this is that open code matters less because it's definitively the best agent today and more because it shows where this market is going next. The next fight is not just over model quality. It is over who owns the interface, the workflow, and the default home for coding with agents. ([Time 0:03:41](https://share.snipd.com/snip/a0e63d55-ac67-4934-8701-85dfb71e6663)) - **Rust Reality Check Focuses On Ecosystem Gaps** - Rust's reality check surfaces recurring developer pain points without doomism. - Adam notes compile times and borrow checker pain are real but often onboarding issues; ecosystem maturity gaps matter most in domains like embedded and GUI. Transcript: Adam Stacoviak The Rust Project published a reality check. This is not a Rust is doomed post. It is not a victory lap either. More like we talked to a bunch of people and yes, the problems you already think Rust has are in fact the problems people keep running into. The interesting part is the shape of those problems. Compile times are still a thing, but they're not really blockers for most people. The borrow checker is still brutal for beginners, but it bothers experts a lot less, which tells you some of that pain is onboarding pain, not necessarily evidence the language is broken. Async is still messy in the way Rust async has been messy for a while, except in this post, they are pretty explicit. There are actual next steps they think can help. And then you get to the ecosystem story, which is maybe the most important one. A healthy crate ecosystem is Rust's largest strength, but people do not always know which crates to trust, which ones are effectively standard, or whether the thing that they need Exists yet in their domain. In worlds like embedded, GUI, and safety-critical work, that maturity gap gets a lot more obvious. I applaud this post because the intent behind it is awesome. I use Rust daily. I feel this pain every single day. Sure, Rust can be improved, but this shows the project is listening, and it shows they have clear pain points to smooth out where there's friction. ([Time 0:04:42](https://share.snipd.com/snip/20374946-d4bd-4c9e-a477-0febf51b5876)) - **Add Browser SSO To CLIs With WorkOS AuthKit** - Use WorkOS AuthKit to add secure browser-based login to CLI apps without migrating identity stacks. - Michael Greenwich explains the device grant flow lets CLIs link to browser SSO, avoiding pasting secrets into shells. Transcript: Adam Stacoviak Michael, if you didn't know, CLIs are back. They're all the rage. And a major problem I personally have with my CLIs is authorization, authentication. What do you say about WorkOS and Auth for CLI? Michael Greenwich Long live the CLI. We've had a resurgence of it, which I am so thrilled about. We actually have supported CLI Auth for many years at WorkOS. This is something called the device grant flow. It lets you have that really smooth experience where from your CLI app you're building, you can link out to the browser and have the user authenticate through whatever system they have In your app and then bounce back into the browser. So nobody is pasting their credentials or their secrets into the shell itself. Kind of zero knowledge, zero trust way of building OAuth authorization. It works great for existing CLIs. It also works super great if you're building a CLI specifically for agents, which is kind of all the rage now as people are expanding upon that. So WorkOS, we think, is the fastest way to do it. And you can actually do it without migrating your entire user base. You can just layer on the CLI auth. Because WorkOS is so modular, you can just add that in front. We have people doing this for MCP as well, where they just use WorkOS for the MCP authentication gateway and not for the primary identity stack. So it's totally possible today. And I think WorkOS is the fastest way to ship auth in your CLI app you're building. ([Time 0:06:08](https://share.snipd.com/snip/86b7f51b-c290-46e9-91eb-378beba6b743)) - **Building An Open Source TurboTax With AI** - Ryan Lizza used AI to build an open source TurboTax alternative and released it for scrutiny. - Adam describes it as a test of AI lowering costs enough for the public to build credible, high-stakes incumbent-challenging software. Transcript: Adam Stacoviak Ryan Leasey got annoyed enough with TurboTax and the larger tax filing mess that he used AI coding tools to build a free open source alternative and then put it in the public so tax professionals And, quote, actual programmers, end quote, can inspect it. The question is not whether AI can spit out code anymore. We are past that. The better question is whether these tools are good enough to help somebody take a real run at expensive, boring, incumbent software that normal people actually depend on. Tax software is a great test because it is high stakes, full of edge cases, and usually not something you could fake your way through with a polished demo. Ryan is not asking for your trust. He's doing the exact opposite. He's saying, hey, the app i made it is open source vet it if you're a pro if you're a programmer vet it please this isn't about a journalist suddenly becoming a 10x software tax engineer It is whether or not ai lowers the cost enough for we the people to build credible public interest software in markets that used to belong entirely to incumbents. ([Time 0:07:32](https://share.snipd.com/snip/2a3ac814-c7cf-4b1e-87e5-fa08aad99b16)) - **HTTPX Forked Into HTTPXYZ Over Maintenance Risk** - HTTPX was forked to HTTPXYZ due to stalled maintenance and trust erosion upstream. - Adam recounts unreleased fixes since Nov 2024, disabled discussions, and dependency risk prompting a conservative stable fork. Transcript: Adam Stacoviak This is one of those open source stories that sounds niche until you realize how much code quietly depends on it. HTTPX is a very popular HTTP client and Michael Bayesian has now forked it into HTTPXYZ. And the reason is there hasn't been a release of HTTPX since November 2024 fixes were sitting around unreleased and upstream trust has been eroding. Now the real story is not just that somebody got frustrated and made a fork. The issue is project maintenance risk eventually turns into dependency risk. In this case, the fork author points to hidden issues, discussions being turned off, years of talk about a future 1.0, and a growing sense that a widely used package did not have a stable Maintenance path anymore. Obscure utility, it sits underneath a lot of Python software and even high-profile packages like OpenAI's and Anthropix's Python SDKs that have already begun guarding against a Future 1.0 release. The fork's pitch is the interesting part. It is not a rewrite. It is not a revolution, just a stable fork with the motto, quote, move a little faster and not break things, end quote. ([Time 0:08:40](https://share.snipd.com/snip/4cfa30ae-17d7-45f2-8b60-9a18094af886))