Bitwarden's CLI got popped, TypeScript 7.0 dropped, pgBackRest lost its maintainer, and Ubuntu 26.04 LTS shipped

Changelog NewsDeveloper news worth your attention

Adam here! 🚨

Good news! My favorite terminal (besides Ghostty, of course), Warp is now open-source. We talked to Zach Lloyd years ago and did our best to sway him to open source Warp, and now it’s done.

Ok let’s get into the news.

🎙️ Changelog #680: Exploring with agents

This week on the pod, I’m talking with Amelia Wattenberger — designer, data-viz veteran, ex-GitHub Next, and now designing Intent from Augment Code.

What if the last 30% of any software project is about to become the hardest part you’ve ever done? That’s the argument Amelia is making today. We discuss the identity crisis developers are having as agents take over the keyboard, the epic redesign of developer tooling in this agent-first world, the arc from autocomplete to chat to CLI back to UI, why Intent treats a workspace as their core primitive not a chat thread, the tradeoffs between one-worktree-per-agent vs. one-worktree-per-task, and why she thinks prototyping just got easier but finishing got harder.

🔓 Bitwarden CLI compromised

Bitwarden’s command-line tool was compromised] last Thursday. Our friends at Socket flagged a malicious package (@bitwarden/cli 2026.4.0) published to npm as part of the same Checkmarx-themed supply-chain campaign that’s been quietly working through developer tooling for weeks.

Why it matters: The CLI is the tool that, by definition, sits next to your secrets, and the compromised build was scraping GitHub tokens, AWS, Azure, and GCP credentials, npm config, SSH keys, shell profiles, even Claude and MCP config files out to a spoofed audit.checkmarx.cx endpoint. If you ran bw on a dev machine or CI runner in the last few days, this is incident response, not a patch cycle.

What they’re saying: “The compromise follows the same GitHub Actions supply chain vector identified in the broader Checkmarx campaign,” Socket Research Team.

Zoom out: This is the pattern, not the incident. Attackers aren’t going after password vaults anymore. They’re going after the tools we use to manage credentials, because those tools already run with the trust to read them. Bitwarden CLI last week. Vercel’s OAuth breach the same week. LiteLLM’s poisoned .pth a few weeks back. The trust boundary in 2026 is your laptop and your CI runner, and that’s exactly where attackers are setting up camp. So: audit your tooling, rotate your tokens, and treat anything that touches your credentials like the high-value target it actually is.

⚡ TypeScript 7.0 Beta

TypeScript 7.0 beta was announced last Tuesday. After more than a year of porting from a JavaScript-bootstrapped compiler to a Go rewrite, the team is shipping it with the headline number “about 10x faster than 6.0.”

The big picture: This is the most ambitious thing TypeScript has done since the language shipped. Microsoft didn’t add features. They rewrote the core in a different language to break a performance ceiling that JS-bootstrapped tsc was never going to clear. This targets exactly what makes large TypeScript codebases painful: your editor’s TypeScript service, your CI’s tsc –noEmit, your monorepo’s incremental build. Stable will be here “within the next two months,”.

What they’re saying: “It is highly stable, highly compatible, and ready to be put to the test in your daily workflows and CI pipelines today.” Daniel Rosenwasser, TypeScript Program Manager, Microsoft

What to watch: Three things I’m watching over the next two months. First, real CI numbers from big monorepos. Everyone’s quoting 10x, but your repo lands somewhere on the curve and the variance is the actual story. Second, editor responsiveness. The new beta extension just shipped auto-imports, expandable hovers, inlay hints, and code lenses, so the language service is the other perf axis worth poking at. Third, whether the ecosystem (ESLint, type-aware linters, anything reaching into tsc internals) catches up before 7.0 stable. The compiler is structurally compatible with 6.0, but the ecosystem won’t all be ready day one.

đź’° Secure environments for devs and agentsThanks to Coder for sponsoring Changelog News

Open by design. Secure by default. Protecting developers laptops with secure environments where devs and agents work in parallel.

Give your developers room to build and run parallel agents inside secure, self-hosted environments. Coder brings developers and agents together on YOUR infrastructure, enabling governed AI adoption with the boundaries and policies your platform and ops teams control.

Learn more at Coder.com

🦝 Ubuntu 26.04 LTS

Resolute Raccoon shipped on Thursday. Ubuntu 26.04 LTS lands with five years of standard support, ten with Ubuntu Pro, and TPM-backed full-disk encryption ready out of the box.

What’s new: TPM-backed FDE is the headline platform feature: disk encryption rooted in a hardware key instead of a typed passphrase. Livepatch now extends to ARM. Rust coreutils ships in 26.04 at 0.8.0 with most of the security fixes applied, but cp, mv, and rm are deliberately not swapped over yet because TOCTOU bugs in the Rust versions didn’t land in time. The stated goal is 100% Rust coreutils by 26.10.

What they’re saying: “cp, mv, and rm continue to be provided by GNU coreutils in 26.04. These utilities have remaining open TOCTOU (time-of-check to time-of-use) issues (8 as of Apr 22, 2026) that need to be resolved before we are confident shipping them.” From Ubuntu’s rust-coreutils update on Discourse.

The takeaway: This is the LTS your servers will run for the next five years, or ten with Pro, through April 2036. The most interesting call in the release isn’t the kernel or the desktop, it’s Canonical pumping the brakes on the Rust coreutils swap for the three commands you actually use every day. That’s a “ship safety, not branding” decision, and it’s the kind of judgment that makes an LTS worth trusting. Start planning your fleet upgrade window now. If Rust-everywhere lands by 26.10 as targeted, this LTS is the on-ramp.

❤️ Spinel compiles Ruby to native binaries

Matz dropped Spinel on Friday. It’s an ahead-of-time compiler that takes Ruby source, emits standalone C, and runs it through gcc or clang to produce a native binary. It achieved a geometric mean of ~11.6x speedup over CRuby miniruby across 28 benchmarks.

Zoom in: Spinel parses with libprism, runs whole-program type inference, generates optimized C, and links against a small sp_runtime.h. No LLVM, no Cranelift, just C that any toolchain can compile. The compiler is self-hosting. The backend is written in Ruby and compiles itself into a native binary. This isn’t a weekend experiment, it’s a serious bootstrap that’s already proven it can compile its own implementation.

Word on the street: “The compiler backend is written in Ruby and compiles itself into a native binary.” From the README.

Looking ahead: This changes the framing for what Ruby can be used for. The immediate, obvious win is small CLIs, Lambda functions, and short-lived processes, anywhere CRuby’s startup cost has been the tax that pushed teams to Go or Rust. The longer arc is more interesting: an AOT path with whole-program type inference is the foundation under “Ruby on more serious infrastructure.” There’s a real ceiling here. No eval, no send or method_missing, no threads, and that’s a lot of the dynamism Rubyists rely on. But the cleanest read is that Matz is signaling Ruby’s future has a typed, pre-compiled lane next to its dynamic one. The Crystal community has been making this case for years. The difference is, this one comes from Matz himself, which means it’s not a

🪦 pgBackRest is no longer being maintained

After thirteen years, David Steele has stepped away from pgBackRest. The repo is archived. The README leads with a “NOTICE OF OBSOLESCENCE.” The standard backup tool for production Postgres has lost its maintainer and won’t be patched going forward.

Reality check: This isn’t a hobby crate going dormant. pgBackRest is the tool a lot of ops teams have woven into runbooks, backup automation, and disaster-recovery plans. When the maintainer of your backup tool stops shipping, the next CVE doesn’t get patched. Not eventually, not at all. And backup tooling is exactly where you do not want unmaintained software, because silent breakage during a real recovery is the worst possible time to find out.

Word on the street: “Rather than do the work poorly and/or sporadically, I think it makes more sense to have a hard stop.” David Steele, original pgBackRest maintainer, in the project’s notice of obsolescence.

The bottom line: If you run pgBackRest in production, this is a this-week task. Steele also noted that since Crunchy Data was sold he hasn’t been able to find a position that lets him continue the work, which is the structural story under the headline. Audit your pgBackRest version. Read the issues queue for known unfixed problems. Start the alternative-evaluation now (Barman, WAL-G, pg_basebackup workflows, or a community fork if one emerges) and put a deadline on the conversation. Don’t let “we’ll deal with it later” turn into “we needed it last night.”

âś… BONUS (un)ordered list

Laters!

-Adam