Container ma­chine pro­vides a highly in­te­grated Linux en­vi­ron­ment that works seam­lessly on your Mac. Container ma­chines are fast, light­weight and per­sis­tent. They are based on stan­dard OCI im­ages that can be built and shared. Host in­te­gra­tions such as au­to­matic user and home di­rec­tory shar­ing pro­vide quick and easy ac­cess to your Linux en­vi­ron­ment no mat­ter where you are in a ter­mi­nal.

Why con­tainer ma­chines

Containers are typ­i­cally mod­eled af­ter an ap­pli­ca­tion. A con­tainer ma­chine is mod­eled af­ter a Linux en­vi­ron­ment. It runs the im­age’s init sys­tem al­low­ing you to reg­is­ter long run­ning ser­vices or test your ap­pli­ca­tion un­der a process su­per­vi­sor. A con­tainer ma­chine au­to­mat­i­cally maps your user­name and home di­rec­tory into the Linux en­vi­ron­ment. Your repos­i­to­ries and dot­files are avail­able on both plat­forms. Use ed­i­tors and tools di­rectly on ma­cOS si­mul­ta­ne­ously build­ing and run­ning your ap­pli­ca­tion in­side of the Linux en­vi­ron­ment.

Edit on the Mac, build in­side. Your repo lives in $HOME on ma­cOS and is mounted at /Users/<username> in­side the con­tainer ma­chine. Use your ma­cOS ed­i­tor or IDE; com­pile and run in­side your con­tainer ma­chine.

Use ma­cOS-na­tive tool­ing against Linux ar­ti­facts. Profilers, screen­shot tools, browsers, and GUI de­bug­gers on your Mac all see the same files the con­tainer ma­chine sees — there is no copy step be­tween “I built it” and “I am in­spect­ing it”.

Real Linux ser­vices for test­ing. Run a data­base or what­ever your stack needs as a sys­tem ser­vice — sys­tem­ctl start post­gresql works on im­ages with sys­temd in­stalled.

One en­vi­ron­ment per tar­get dis­tro. Create as many con­tainer ma­chines as you have tar­get dis­tros — alpine, ubuntu, de­bian. Each has the same $HOME and the same dot­files from your Mac. Quickly test your ap­pli­ca­tion in var­i­ous dis­tri­b­u­tions.

Quickstart

con­tainer ma­chine cre­ate alpine:lat­est –name dev con­tainer ma­chine run -n dev whoami # your host user­name, not root con­tainer ma­chine run -n dev pwd # /home/<you> — your Mac home dir, mounted in con­tainer ma­chine run -n dev # in­ter­ac­tive shell; cd into your re­pos in $HOME

con­tainer ma­chine run is how you get a shell or run a sin­gle com­mand. If the con­tainer ma­chine is stopped, run boots it first.

Working in a con­tainer ma­chine

Open a shell, or run a sin­gle com­mand

With no com­mand, con­tainer ma­chine run opens an in­ter­ac­tive shell as a user that matches your host ac­count:

con­tainer ma­chine run -n dev

Pass a com­mand to run it once and exit:

con­tainer ma­chine run -n dev un­ame -a con­tainer ma­chine run -n dev — cat /proc/cpuinfo

Set a de­fault

Pick a de­fault con­tainer ma­chine so you can drop the -n flag:

con­tainer ma­chine set-de­fault dev con­tainer ma­chine run # op­er­ates on dev

List, in­spect, stop, delete

con­tainer ma­chine ls # list all con­tainer ma­chines con­tainer ma­chine in­spect dev # JSON de­tail for one con­tainer ma­chine stop dev # stop the con­tainer ma­chine con­tainer ma­chine rm dev # delete, in­clud­ing its per­sis­tent stor­age

con­tainer ma­chine has the alias m, so m ls, m run, etc. all work.

Resize CPUs, mem­ory, or change the home-mount

con­tainer ma­chine set up­dates con­fig­u­ra­tion on disk. Changes take ef­fect af­ter the next stop and start:

con­tainer ma­chine set -n dev cpus=4 mem­ory=8G con­tainer ma­chine stop dev con­tainer ma­chine run -n dev — nproc

Memory de­faults to half of host mem­ory. The home-mount can be rw (default), ro, or none.

Bring your own con­tainer ma­chine im­age

Any Linux im­age that in­cludes /sbin/init works as a con­tainer ma­chine. For ex­am­ple, this Dockerfile builds an Ubuntu 24.04 con­tainer ma­chine im­age with sys­temd and com­mon com­mand-line tools:

FROM ubuntu:24.04

ENV con­tainer con­tainer

RUN apt-get up­date && \ apt-get in­stall -y \ dbus sys­temd openssh-server net-tools iproute2 iputils-ping curl wget vim-tiny man sudo && \ apt-get clean && \ rm -rf /var/lib/apt/lists/* && \ yes | un­min­i­mize

RUN >/etc/machine-id RUN >/var/lib/dbus/machine-id

RUN sys­tem­ctl set-de­fault multi-user.tar­get RUN sys­tem­ctl mask \ dev-hugepages.mount \ sys-fs-fuse-con­nec­tions.mount \ sys­temd-up­date-utmp.ser­vice \ sys­temd-tmp­files-setup.ser­vice \ con­sole-getty.ser­vice RUN sys­tem­ctl dis­able \ net­workd-dis­patcher.ser­vice

RUN sed -i -e ‘s/^AcceptEnv LANG LC_\*$/#AcceptEnv LANG LC_*/’ /etc/ssh/sshd_config

Build it and cre­ate a con­tainer ma­chine from it:

con­tainer build -t lo­cal/​ubuntu-ma­chine:lat­est . con­tainer ma­chine cre­ate lo­cal/​ubuntu-ma­chine:lat­est –name ubuntu

By de­fault, con­tainer runs a built-in setup script on first boot to pro­vi­sion the user de­scribed above. To use your own setup in­stead, add an ex­e­cutable script at /etc/machine/create-user.sh to the im­age. It runs once, as root, on first boot, with these vari­ables set:

CONTAINER_GID

CONTAINER_HOME

CONTAINER_MACHINE_ID

CONTAINER_UID

CONTAINER_USER

I did­n’t ex­pect to read this in a model card.

Fable 5 model card :

we’ve im­ple­mented new in­ter­ven­tions that limit Claude’s ef­fec­tive­ness for re­quests tar­get­ing fron­tier LLM de­vel­op­ment (for ex­am­ple, on build­ing pre­train­ing pipelines, dis­trib­uted train­ing in­fra­struc­ture, or ML ac­cel­er­a­tor de­sign). Using Claude to de­velop com­pet­ing mod­els al­ready vi­o­lates our Terms of Service, but en­forc­ing this re­stric­tion through our safe­guards avoids ac­cel­er­at­ing the ac­tors most will­ing to vi­o­late these terms. Unlike our in­ter­ven­tions for cy­ber­se­cu­rity, bi­ol­ogy and chem­istry, and dis­til­la­tion at­tempts, these safe­guards will not be vis­i­ble to the user. Fable 5 will not fall back to a dif­fer­ent model. Instead, the safe­guards will limit ef­fec­tive­ness through meth­ods such as prompt mod­i­fi­ca­tion, steer­ing vec­tors, or pa­ra­me­ter-ef­fi­cient fine-tun­ing (PEFT).

we’ve im­ple­mented new in­ter­ven­tions that limit Claude’s ef­fec­tive­ness for re­quests tar­get­ing fron­tier LLM de­vel­op­ment (for ex­am­ple, on build­ing pre­train­ing pipelines, dis­trib­uted train­ing in­fra­struc­ture, or ML ac­cel­er­a­tor de­sign). Using Claude to de­velop com­pet­ing mod­els al­ready vi­o­lates our Terms of Service, but en­forc­ing this re­stric­tion through our safe­guards avoids ac­cel­er­at­ing the ac­tors most will­ing to vi­o­late these terms. Unlike our in­ter­ven­tions for cy­ber­se­cu­rity, bi­ol­ogy and chem­istry, and dis­til­la­tion at­tempts, these safe­guards will not be vis­i­ble to the user. Fable 5 will not fall back to a dif­fer­ent model. Instead, the safe­guards will limit ef­fec­tive­ness through meth­ods such as prompt mod­i­fi­ca­tion, steer­ing vec­tors, or pa­ra­me­ter-ef­fi­cient fine-tun­ing (PEFT).

Claude can now be silently nerfed. Anthropic has de­cided it won’t tell users when this hap­pens.

Modern soft­ware com­pa­nies in­creas­ingly build their own em­bed­ding, rerank­ing, and rec­om­men­da­tion sys­tems. Even my small boot­strapped app, wan­derfugl.com, has a cus­tom reranker and em­bed­ding al­go­rithm that I trained my­self.

Anthropic gives a few ex­am­ples of what it con­sid­ers “frontier AI de­vel­op­ment,” but does­n’t pro­vide a clear line. The prob­lem is that many tech­niques once re­served for AI labs are now be­ing used by or­di­nary soft­ware com­pa­nies. Startups train em­bed­ding mod­els. They build rerankers. They fine­tune and host small llms. The bound­ary be­tween “frontier AI re­search” and nor­mal prod­uct de­vel­op­ment is be­com­ing harder to de­fine every year.

That cre­ates a real sup­ply chain risk for busi­nesses. If Claude gives me poor or in­cor­rect ad­vice while I’m work­ing on an AI com­po­nent, I have no way of know­ing whether the model was con­fused, whether my prob­lem is un­solv­able, or if some in­vis­i­ble pol­icy re­stric­tion qui­etly kicked in. Anthropic has ex­plic­itly cho­sen not to tell users when this is hap­pen­ing.

Once a de­vel­op­ment tool can stop op­ti­miz­ing for your suc­cess with­out telling you, it be­comes im­pos­si­ble to fully trust your in­fra­struc­ture.

The Anthropic sup­ply chain risk

Anthropic says these safe­guards only af­fect 0.03% of de­vel­op­ers. Maybe that’s true to­day.

The prob­lem is that the de­f­i­n­i­tion of an AI com­pany is chang­ing.

Maybe you’re not train­ing fron­tier mod­els to­day—most com­pa­nies aren’t. But mod­ern soft­ware in­creas­ingly con­tains AI mod­els. Five years ago, build­ing a startup meant writ­ing APIs and SQL queries. Today, it of­ten means train­ing, tun­ing, and de­ploy­ing mod­els.

Five years ago, mod­els like CLIP were fron­tier AI re­search pro­jects. Today I’m fine-tun­ing them for a boot­strapped travel startup.

If you’re de­bug­ging a model train­ing pipeline for your prod­uct and Claude gives a bad an­swer, was the model con­fused? Did you give it bad con­text? Or did a hid­den pol­icy nerf Claude’s abil­ity to as­sist you?

You won’t know.

A German court has ruled that Google is di­rectly li­able for what its AI search overviews say. Previous case law shield­ing search en­gine op­er­a­tors from li­a­bil­ity does­n’t ap­ply to AI overviews.

The Regional Court of Munich hit Google with a tem­po­rary in­junc­tion bar­ring the com­pany from spread­ing false claims about two Munich-based pub­lish­ers through its AI-generated search overviews (case no. 26 O 869/26). The court clas­si­fied Google as a di­rect in­fringer be­cause the “AI overview” is its own con­tent, not just a list of search re­sults.

Google’s AI overviews had falsely tied two pub­lish­ing com­pa­nies to scams, sub­scrip­tion traps, and shady busi­ness prac­tices for cer­tain search queries. According to the court, the AI mixed up in­for­ma­tion about other, gen­uinely sketchy com­pa­nies with the plain­tiffs and drew con­nec­tions that did­n’t ap­pear in any of the linked sources. The pub­lish­ers sent Google a cease-and-de­sist let­ter, but Google did­n’t re­spond ap­pro­pri­ately.

AI overviews aren’t search re­sults

Google’s AI overviews work noth­ing like tra­di­tional search re­sults, the court ar­gues. The AI rewrites and judges re­sults “in its own words and ac­cord­ing to its own struc­ture,” the rul­ing says. In the case at hand, for ex­am­ple, it opened with con­fi­dent claims like “Yes, [company] is known for du­bi­ous busi­ness prac­tices,” then built its own struc­ture with a sum­mary, red flags for the al­leged scam, and tips for users.

The court also found that the AI overview made claims “that are not even made in the search re­sults.” None of the linked sources drew any con­nec­tion be­tween the plain­tiffs and the shady com­pa­nies the AI men­tioned. The court called these “the de­fen­dan­t’s own state­ments.”

Google built the AI, Google of­fered it to users, so Google owns what it pro­duces, “because it alone has in­flu­ence over the AI’s of­fer­ing and the al­go­rithms with which the AI op­er­ates.”

Search en­gine li­a­bil­ity rules don’t ap­ply to AI “search”

The court also ex­am­ined ex­ist­ing rul­ings from Germany’s Federal Court of Justice (BGH), which gave tra­di­tional search en­gines and au­to­com­plete lim­ited li­a­bil­ity. The BGH had ar­gued that search en­gine op­er­a­tors were only li­able as in­di­rect in­fringers be­cause they merely made third-party con­tent find­able. A proac­tive duty to check re­sults would threaten how search en­gines work.

The Munich court found that this rea­son­ing does­n’t ap­ply to AI overviews. A reg­u­lar search en­gine just points to out­side web­sites. But AI overviews gen­er­ate “independent, new, and sub­stan­tive state­ments” by eval­u­at­ing and com­bin­ing con­tent from var­i­ous third-party sites. And only Google can check those state­ments, the court said, “at least by com­par­ing the un­der­ly­ing third-party web­sites with its own state­ments based on them.”

The court also noted that the AI overview is “by no means ab­solutely nec­es­sary” for us­ing the in­ter­net. Traditional search re­sults al­ready help users sort through in­for­ma­tion, the AI overview is just an ex­tra fea­ture.

Google’s “users can check for them­selves” de­fense falls flat

At the hear­ing, Google ar­gued that users could check the linked sources them­selves to ver­ify whether the AI sum­mary was cor­rect. Users gen­er­ally knew “that in­for­ma­tion gen­er­ated with AI should not be blindly trusted,” the com­pany claimed. That’s a re­mark­able state­ment given the scale at which Google serves AI overviews. It’s also not en­tirely true, since the con­nec­tion be­tween sources and gen­er­ated con­tent is­n’t al­ways there.

The court re­jected this. The pos­si­bil­ity of dis­prov­ing a state­ment through fur­ther re­search does­n’t “regularly ex­empt from li­a­bil­ity for this state­ment.” The AI overview was “understandable on its own” and con­tained “a self-con­tained state­ment with in­de­pen­dently un­der­stand­able con­tent and no ref­er­ence to other pos­si­ble in­ter­pre­ta­tions or even un­re­li­able con­tent.” Stud­ies show that users al­most never click on sources in AI overviews, which sup­ports the court’s rea­son­ing.

The court drew a par­al­lel to press law, where pub­lish­ers are li­able for teasers that are un­der­stand­able on their own, even if read­ers never read the full ar­ti­cle. Google’s own ar­gu­ment would also “significantly di­min­ish” the ben­e­fit of the fea­ture, the court noted, if the overview were “generally rec­og­nized as un­re­li­able.”

The court also pointed to a pro­tec­tion gap. If Google were only li­able for ob­vi­ous vi­o­la­tions, vic­tims would have no real le­gal re­course when the AI makes false claims. The third par­ties whose web­sites served as sources had­n’t even made the state­ments in ques­tion. So vic­tims could­n’t sue the sources, and un­der ex­ist­ing rules they could­n’t ef­fec­tively sue Google ei­ther.

As a re­sult, Google could­n’t in­voke host provider pro­tec­tions un­der the Digital Services Act or fall back on the stan­dard no­tice-and-take-down process for search en­gines.

AI-generated opin­ions get less free speech pro­tec­tion

As if the rest was­n’t bad enough for Google, the court also went af­ter free speech pro­tec­tion for AI-generated con­tent. An AI’s opin­ion is “not the ex­pres­sion of an ac­quired con­vic­tion of the per­sons ex­press­ing it, but the re­sult of an al­go­rithm,” the court wrote.

Offering AI-powered re­search is “above all an ex­pres­sion of Google’s busi­ness ac­tiv­i­ties” and “at most a sec­ondary ex­pres­sion of an in­ter­est in be­ing able to freely ex­press one’s opin­ion and be­liefs.”

When weigh­ing the plain­tiffs’ pri­vacy rights against Google’s in­ter­ests, Google had to take a back seat, es­pe­cially since the chal­lenged state­ments were based on un­true facts. The AI had linked the plain­tiffs to com­pa­nies that, ac­cord­ing to sworn af­fi­davits, had no con­nec­tion to them what­so­ever.

Google picks up 80 per­cent of the le­gal tab

The court ruled in fa­vor of the plain­tiffs on most counts. It banned claims about scams, con­nec­tions to du­bi­ous com­pa­nies, sub­scrip­tion traps, phone calls that never hap­pened, and lack of avail­abil­ity. Only two mi­nor re­quests got de­nied.

The risk of re­peated vi­o­la­tions re­mained, even though the spe­cific texts were no longer be­ing dis­played. Google had­n’t is­sued a cease-and-de­sist de­c­la­ra­tion with a penalty clause, and noth­ing stopped the al­go­rithms from gen­er­at­ing the same state­ments again. Google cov­ers 80 per­cent of the le­gal costs; the plain­tiffs pay 10 per­cent each.

The rul­ing may also have in­ter­na­tional reach, ac­cord­ing to the court.

Even a 91 per­cent ac­cu­racy rate means mil­lions of wrong an­swers

The Munich rul­ing goes far be­yond this one case. An analysis by AI startup Oumi for the New York Times found that Google’s AI Overviews with the cur­rent Gemini 3 model an­swered cor­rectly 91 per­cent of the time.

That’s solid enough for every­day use by most peo­ple. But at Google’s scale, it still means mil­lions of wrong an­swers every hour. If enough of that wrong con­tent de­fames com­pa­nies or in­di­vid­u­als, it could be­come a se­ri­ous le­gal prob­lem not just for Google but for other providers of sim­i­lar ser­vices like ChatGPT, Claude, or Perplexity.

The Oumi analy­sis also found that 56 per­cent of the cor­rect Gemini 3 an­swers could­n’t be backed up by the sources Google linked. The AI is giv­ing an­swers whose ori­gins users can’t trace.

The Munich court tack­led ex­actly this prob­lem: the AI makes its own claims that don’t ap­pear in any linked source, and the op­er­a­tor has to an­swer for them. Whether this rea­son­ing holds up on ap­peal re­mains to be seen, and Google has­n’t com­mented on the rul­ing. But if it gains trac­tion in­ter­na­tion­ally, the fall­out could hit not just Google but every AI provider whose sys­tems para­phrase con­tent from the web.

Jun 10, 2026

This is a story of how build­ing HTML-first dou­bled a com­pa­ny’s users lit­er­ally overnight.

My client was a util­ity com­pany, and they had a big prob­lem. To ap­ply for their ser­vices, cus­tomers could ei­ther use an old ASP form on the web­site, or fol­low a man­ual process. The man­ual process was more ex­pen­sive for the com­pany, of course. Adding a lot of pres­sure, this was a reg­u­lated mo­nop­oly, and if their cus­tomer sat­is­fac­tion dropped be­low 96% (if I re­mem­ber cor­rectly) it could re­sult in mil­lions of pounds in fines.

There were two pre­vi­ous failed (and very ex­pen­sive) at­tempts to solve the prob­lem. In the most re­cent, con­trac­tors in an­other coun­try had built a React app. The React app was on­line for 3 days be­fore be­ing pulled be­cause of cus­tomer com­plaints. I took one look at it and told my boss “we can’t take own­er­ship of this.” It was a mess of load­ing spin­ners and global javascript states. It was not ac­ces­si­ble. Image up­load was a vi­tal part of the form, and it at­tempted to store im­ages (along with all other form data) in lo­cal­stor­age which has a 5mb limit!

I took a very bold de­ci­sion and built a new ver­sion of the site us­ing Astro. It was HTML-first. Javascript ex­isted, in web com­po­nents, but only to pro­gres­sively-en­hance a web­site that worked per­fectly fine with­out it.

My logic was thus:

This is a pub­lic ser­vice

It should work on every ma­chine pos­si­ble

It should work when con­nec­tions are poor

The forms must never lose data once it is en­tered

I was very moved by this anec­dote from Terence Eden:

A few years ago I was do­ing pol­icy re­search in a hous­ing ben­e­fits of­fice in London. They are sin­gu­larly unlovely places. The walls are bright­ened up with posters of­fer­ing help­ful ser­vices for peo­ple flee­ing do­mes­tic vi­o­lence. The se­cu­rity guards on the door are cau­tiously in­dif­fer­ent to any­one walk­ing in. The air is filled with tense con­ver­sa­tions be­tween part­ners - drowned out by the noise of scream­ing kids. In the mid­dle, a young woman sits on a hard plas­tic chair. She is sur­rounded by can­vas-bags con­tain­ing her worldly pos­ses­sions. She does­n’t look like she is in a great emo­tional place right now. Clutched in her hands is a games con­sole - a PlayStation Portable. She stares at it in­tensely; block­ing out the world with Candy Crush. Or, at least, that’s what I thought. Walking be­hind her, I glance at her con­sole and recog­nise the screen she’s on. She’s con­nected to the com­ple­men­tary WiFi and is brows­ing the GOV.UK pages on Housing Benefit. She’s not slic­ing fruit; she’s arm­ing her­self with knowl­edge. The PSP’s web browser is - char­i­ta­bly - pa­thetic. It is slow, fre­quently runs out of mem­ory, and can only open 3 tabs at a time. But the GOV.UK pages are writ­ten in sim­ple HTML. They are de­signed to be light­weight and will work even on rub­bish browsers. They have to. This is for every­one.

A few years ago I was do­ing pol­icy re­search in a hous­ing ben­e­fits of­fice in London. They are sin­gu­larly unlovely places. The walls are bright­ened up with posters of­fer­ing help­ful ser­vices for peo­ple flee­ing do­mes­tic vi­o­lence. The se­cu­rity guards on the door are cau­tiously in­dif­fer­ent to any­one walk­ing in. The air is filled with tense con­ver­sa­tions be­tween part­ners - drowned out by the noise of scream­ing kids.

In the mid­dle, a young woman sits on a hard plas­tic chair. She is sur­rounded by can­vas-bags con­tain­ing her worldly pos­ses­sions. She does­n’t look like she is in a great emo­tional place right now. Clutched in her hands is a games con­sole - a PlayStation Portable. She stares at it in­tensely; block­ing out the world with Candy Crush.

Or, at least, that’s what I thought.

Walking be­hind her, I glance at her con­sole and recog­nise the screen she’s on. She’s con­nected to the com­ple­men­tary WiFi and is brows­ing the GOV.UK pages on Housing Benefit. She’s not slic­ing fruit; she’s arm­ing her­self with knowl­edge.

The PSP’s web browser is - char­i­ta­bly - pa­thetic. It is slow, fre­quently runs out of mem­ory, and can only open 3 tabs at a time.

But the GOV.UK pages are writ­ten in sim­ple HTML. They are de­signed to be light­weight and will work even on rub­bish browsers. They have to. This is for every­one.

Some re­quire­ments I de­rived:

Each ses­sion with the form should have a unique ID

At every step in the form wiz­ard, sub­mit­ted data should be stored on the back­end, in­clud­ing up­loads

It should be pos­si­ble to com­plete the form with­out javascript

It should be pos­si­ble to com­plete the form on out­dated and crap web browsers

We had to meet WCAG ac­ces­si­bil­ity (the team set­tled on AA rather than AAA)

Javascript and mod­ern CSS should be used to en­hance the ex­pe­ri­ence

The ba­sic setup ended up be­ing that each step in the form wiz­ard was its own page. When the user clicked next, the form would sub­mit. If the data was judged to be valid by the API, the browser would be redi­rected to the next step.

A ven­er­a­ble web ap­pli­ca­tion pat­tern that has had a small mod­ern re­nais­sance thanks to Remix, form sub­mis­sions and redi­rects took a while to ex­plain to my col­leagues, on ac­count of every­one be­ing used to heav­ily client-side web ap­pli­ca­tions. I have noth­ing against heav­ily client-side ap­pli­ca­tions, in their place. But this is just a big form - it’s not show­ing real-time data. Our user could be stand­ing in the mid­dle of a field on a new-build hous­ing es­tate, hold­ing a decade-old com­mod­ity an­droid phone they bought in Tesco. Shipping them 20MB of javascript be­fore we even ren­der a form would be a ridicu­lous thing to do.

Next, I tack­led one of my biggest bug­bears, form val­i­da­tion (and form and form er­ror ren­der­ing). I have seen teams waste per­son-months of ef­fort wran­gling React val­i­da­tion li­braries. If you are a React per­son, you might be scoff­ing at this - skill is­sue, I guess - but it is the re­al­ity for many teams. I would like to humbly sug­gest that you too may be spend­ing more time than you re­alise, and a lot more time than is nec­es­sary, in­ter­act­ing with and main­tain­ing poor im­i­ta­tions of the val­i­da­tion sys­tem that ships with every browser.

So I built an HTML web com­po­nent. These are sim­ple cus­tom el­e­ments that wrap around ex­ist­ing HTML and bring it to life. No shadow DOM, no (or lit­tle) ren­der­ing HTML in javascript. Mine wrapped around any HTML form, picked up the HTML val­i­da­tion, and made it look mod­ern. It would pre­vent those HTML val­i­da­tion popup tooltips, and in­stead place the er­ror in the aria-de­scribedby el­e­ment as­so­ci­ated with the field (today, aria-er­rormes­sage is ad­vised in­stead). It would clear val­i­da­tion while you typed, if you reached a valid state, and as­sess it again on blur and sub­mit.

Exactly the user ex­pe­ri­ence a form needs, de­liv­ered in un­der 1KB. If it failed, the form would fall back to built-in browser val­i­da­tion. If that failed, the back­end API would han­dle val­i­da­tion. We re­ported val­i­da­tion is­sues to the user as early as pos­si­ble given their browser, and al­ways fell back to an ac­cept­able ex­pe­ri­ence if it failed.

I have since writ­ten a new ver­sion of this web com­po­nent from scratch, aimed for gen­eral use. It’s called val­i­da­tion-en­hancer. I have been in this in­dus­try for over 20 years, and it is the best form val­i­da­tion li­brary I have ever used. I am very proud of it.

The code is so sim­ple to work with:

<validation-enhancer> <form>

<label for=“my-email”>Email</​la­bel> <input type=“email” name=“my-email” aria-er­rormes­sage=“my-email-er­ror” re­quired /> <div id=“my-email-er­ror”></​div>

<button type=“sub­mit”>Sub­mit</​but­ton> </form> </validation-enhancer>

The re­sults? When we launched, the num­ber of peo­ple com­plet­ing the form dou­bled. The an­a­lyt­ics peo­ple did­n’t even know where these users were com­ing from. Of course, your javascript-based an­a­lyt­ics pack­age does­n’t see the users you are bounc­ing be­cause of javascript fail­ures. It was a flood! We also saw my “keep a back­end ses­sion, never lose user data” ap­proach pay off. In one case, some­one com­pleted a form a month af­ter start­ing it.

There was a sad coda; as is the way of con­tract work, I moved on. I ex­plained what I had built to my re­place­ment, that it al­ways worked even with­out javascript. He was ap­palled and said, “but that’s a lot more work for us.”

It is not ac­cept­able to bounce users on old browsers, users with bad net­work con­nec­tions, users us­ing as­sis­tive tech­nolo­gies. Certainly not from a mo­nop­oly pub­lic ser­vice. A lot of hype and noise is press­ing us to ex­tend the cow­boy, wild-west phase of the soft­ware in­dus­try’s ex­pan­sion. We should set that aside, and take our­selves se­ri­ously as a ma­ture in­dus­try. Build a web ap­pli­ca­tion that works on a playsta­tion portable on a 3G con­nec­tion - if you do, it will work for all your users, and it will still work 30 years from now.

Our next npm ma­jor ver­sion, v12, in­tro­duces se­cu­rity-re­lated de­fault changes to npm in­stall. All these changes are avail­able be­hind warn­ings in npm to­day on 11.16.0 or newer, so you can pre­pare be­fore the up­grade. v12 is es­ti­mated to re­lease in July 2026.

Each change turns an npm in­stall be­hav­ior that runs au­to­mat­i­cally to­day into one you ex­plic­itly opt into:

al­lowScripts de­faults to off: npm in­stall will no longer ex­e­cute pre­in­stall, in­stall, or postin­stall scripts from de­pen­den­cies un­less they are ex­plic­itly al­lowed in your pro­ject. This in­cludes na­tive node-gyp builds (i.e., a pack­age with a bind­ing.gyp and no ex­plicit in­stall script still gets blocked, be­cause npm runs an im­plicit node-gyp re­build for it). pre­pare scripts from git, file, and link de­pen­den­cies are blocked the same way. To see what would be blocked, run npm ap­prove-scripts –allow-scripts-pending. Then al­low the pack­ages you trust with npm ap­prove-scripts and block the rest with npm deny-scripts. The re­sult­ing al­lowlist is writ­ten to pack­age.json and should be com­mit­ted. If your in­stall rou­tine runs scripts, you can ob­serve warn­ings in npm 11.16.0+.

–allow-git de­faults to none: npm in­stall will no longer re­solve Git de­pen­den­cies (direct or tran­si­tive) un­less ex­plic­itly al­lowed via –allow-git. This closes a code-ex­e­cu­tion path where a Git de­pen­den­cy’s .npmrc could over­ride the Git ex­e­cutable, even with –ignore-scripts. This change was pre­vi­ously an­nounced on 2026 – 02-18 and is avail­able in npm 11.10.0+.

–allow-git de­faults to none: npm in­stall will no longer re­solve Git de­pen­den­cies (direct or tran­si­tive) un­less ex­plic­itly al­lowed via –allow-git. This closes a code-ex­e­cu­tion path where a Git de­pen­den­cy’s .npmrc could over­ride the Git ex­e­cutable, even with –ignore-scripts. This change was pre­vi­ously an­nounced on 2026 – 02-18 and is avail­able in npm 11.10.0+.

–allow-remote de­faults to none: npm in­stall will no longer re­solve de­pen­den­cies from re­mote URLs, such as https tar­balls (direct or tran­si­tive), un­less ex­plic­itly al­lowed via –allow-remote. This flag is avail­able in npm 11.15.0+. The re­lated –allow-file and –allow-directory flags are not chang­ing their de­faults in v12.

–allow-remote de­faults to none: npm in­stall will no longer re­solve de­pen­den­cies from re­mote URLs, such as https tar­balls (direct or tran­si­tive), un­less ex­plic­itly al­lowed via –allow-remote. This flag is avail­able in npm 11.15.0+. The re­lated –allow-file and –allow-directory flags are not chang­ing their de­faults in v12.

How to pre­pare

Upgrade to npm 11.16.0 or later, run your nor­mal in­stall, and re­view the warn­ings. Use npm ap­prove-scripts –allow-scripts-pending to see which pack­ages have scripts, ap­prove the ones you trust, and com­mit the up­dated pack­age.json. After that, only the scripts you ap­proved keep run­ning once you up­grade. Anything you leave un­ap­proved will stop. More de­tails are avail­able in our docs at npm ap­prove-scripts, npm deny-scripts, and al­low-scripts con­fig (for npx and global in­stalls). Please share your com­ments and ques­tions in our com­mu­nity dis­cus­sion.

Chrome is look­ing to per­ma­nently drop MV2 ex­ten­sions and its by­passes, thus end­ing most uBlock Origin workarounds.

Sayan Sen

Neowin @ssc_combater007 ·

Jun 9, 2026 06:28 EDT

· Hot!

For a while now the tran­si­tion away from Manifest V2 (MV2) to MV3 has been on-go­ing and it looks like it is en­ter­ing its fi­nal phase of dep­re­ca­tion, at least, in the case of Google Chrome. A re­cent dis­cus­sion thread in the w3c WebExtensions Community Group GitHub repo has high­lighted how the lat­est and up­com­ing ver­sions of the most pop­u­lar browser are ex­pected to be its fi­nal re­leases with sup­port for MV2 ex­ten­sions.

Chromium con­trib­u­tor Andrey Bershanskiy shared de­tails about re­cent Chromium changes and ac­cord­ing to com­ments from Google en­gi­neer Devlin Cronin, Chrome has now started re­mov­ing the flags that pre­vi­ously con­trolled MV2 avail­abil­ity. kEx­ten­sion­Man­i­festV2Dis­abled, the Chromium fea­ture flag that al­lowed con­trolled dis­abling of MV2 add-ons, is now com­pletely re­moved, which means you will likely no longer find uBlock Origin in your browser ex­ten­sions list.

He wrote: “The kEx­ten­sion­Man­i­festV2Dis­abled fea­ture has been de­fault-en­abled for over a year. Remove the fea­ture and the ef­fec­tively-dead code. … Any tests that re­lied on be­ing in the “warning” phase (i.e., with the kEx­ten­sion­Man­i­festV2Dis­abled) for their sole be­hav­ior test­ing are re­moved, since this stage is no longer reach­able.”

Cronin fur­ther ex­plained why MV2 ex­ten­sions are no longer al­lowed in sup­ported Chrome ver­sions as main­tain­ing the as­so­ci­ated func­tion­al­ity in­def­i­nitely is no longer pos­si­ble. He cited grow­ing tech­ni­cal dif­fi­cul­ties and im­ple­men­ta­tion com­plex­i­ties as well as se­cu­rity con­cerns.

He wrote: “MV2 ex­ten­sions are no longer al­lowed in any sup­ported ver­sion of Chrome, and we are re­mov­ing sup­port for them and the as­so­ci­ated func­tion­al­ity. We won’t be able to pro­vide / main­tain this func­tion­al­ity in­def­i­nitely due to the com­plex­ity and tech debt, as well as the se­cu­rity risks it en­tails (we’ve ac­tu­ally found a num­ber of bugs that are spe­cific to MV2 lately). Of course, other browsers can con­tinue sup­port­ing these if they so de­sire.

Unfortunately, we won’t be putting code be­hind a com­pi­la­tion flag … We won’t be re­mov­ing all the MV2 code whole­sale right away, so many of these things will con­tinue work­ing for awhile (but they will go away even­tu­ally, and some may go away sooner than oth­ers).”

What this es­sen­tially means is that the tricks and by­passes that were used to keep MV2 ex­ten­sions like uBlock Origin and oth­ers alive will not work any more on Chrome, or at least not for very long. For ex­am­ple the Windows Registry mod that could ex­tend MV2 avail­abil­ity will cease to func­tion af­ter Chromium ver­sion 151.

Here is a run­down of the changes com­ing in the fi­nal such re­leases of Chromium re­leases:

Chromium 150 lost ExtensionManifestV2Disabled op­tion

Chromium 151 will loose ExtensionManifestV2Unsupported op­tion

Chromium 151 will loose ExtensionManifestV2Availability op­tion

Chromium 151 will likely loose AllowLegacyMV2Extensions op­tion

Other Chromium-based browsers like Opera and Microsoft Edge could soon fol­low suit too. Although it is not spec­i­fied, Edge be­gan dis­abling uBlock Origin back in February, and Opera could also stop the func­tion­ing of MV2 add-ons, even though it had com­mit­ted to sup­port MV2 for longer in October 2024.

uBlock Origin de­vel­oper Raymond Hill (gorhill) ap­par­ently stated the fol­low­ing: “For Opera I did sub­mit 1.70.0 rather late, but this was weeks ago. A while ago I re­ceived an email from Opera that they plan to aban­don MV2-based ex­ten­sion so maybe they are no longer al­lo­cat­ing re­sources for re­view­ing such ex­ten­sions.”

The email which de­vel­op­ers like Gorhill men­tions was re­ceived from Opera last year. Here is what it seem­ingly said:

Dear Developers,

This mes­sage is to in­form you of im­por­tant up­com­ing changes re­gard­ing Opera ex­ten­sion sup­port.

Chromium, which pow­ers Opera, is com­pletely re­mov­ing sup­port for Manifest Version 2. If your ex­ten­sion cur­rently uses Manifest Version 2, it is cru­cial that you up­date it to Manifest Version 3 as soon as pos­si­ble to en­sure con­tin­ued com­pat­i­bil­ity.

We strongly ad­vise tak­ing ac­tion to up­date your ex­ten­sions to Manifest Version 3 to avoid any dis­rup­tion of ser­vice and to en­sure a smooth tran­si­tion.

– Sincerely, Opera Extensions Team

Dear Developers,

This mes­sage is to in­form you of im­por­tant up­com­ing changes re­gard­ing Opera ex­ten­sion sup­port.

Chromium, which pow­ers Opera, is com­pletely re­mov­ing sup­port for Manifest Version 2. If your ex­ten­sion cur­rently uses Manifest Version 2, it is cru­cial that you up­date it to Manifest Version 3 as soon as pos­si­ble to en­sure con­tin­ued com­pat­i­bil­ity.

We strongly ad­vise tak­ing ac­tion to up­date your ex­ten­sions to Manifest Version 3 to avoid any dis­rup­tion of ser­vice and to en­sure a smooth tran­si­tion.

– Sincerely, Opera Extensions Team

Hence for now the only Chromium browser that seems to be on-board fully with MV2 sup­port is Brave, and per­haps Vivaldi as well. Meanwhile if you want to ditch Chromium browsers en­tirely then Mozilla Firefox is an ex­cel­lent al­ter­na­tive as MV3 and MV2 are both sup­ported.

Of course the eas­i­est so­lu­tion is to switch to uBlock Origin Lite if you want to re­main on Chrome, as it is MV3-based, but from our ex­pe­ri­ence, uBO Lite does not seem to be as good as the orig­i­nal non-Lite ver­sion.

Source: w3C (GitHub repo)

As an on­line pub­li­ca­tion, Neowin too re­lies on ads for op­er­at­ing costs and, if you use an ad blocker, we’d ap­pre­ci­ate be­ing whitelisted. In ad­di­tion, we have an ad-free sub­scrip­tion for $28 a year, which is an­other way to show sup­port!

Like many de­vel­oper teams, we’ve been get­ting fed up with GitHub Actions. As our PR through­put has gone up, it’s in­creas­ingly ob­vi­ous that our CI ac­tions are too slow and ex­pen­sive.

While there are a lot of ways to mit­i­gate this, we’d been en­cour­aged to try Blacksmith.

Blacksmith is a YC startup that bills it­self as a drop-in re­place­ment for GitHub Actions, but cheaper and faster. So we gave it a try. Blacksmith im­ported our GitHub setup, and… it was faster! Maybe also cheaper, too, though that’s less clear when you’re on the free trial.

We got back to cod­ing, as star­tups do, and be­fore long we got an email about putting in a credit card:

We’re writ­ing to in­form you that you’ve used up 80% of your free min­utes for the forest­walk­labs org this month. Please add a credit card on file to avoid dis­rup­tions to your ser­vice.

We’re writ­ing to in­form you that you’ve used up 80% of your free min­utes for the forest­walk­labs org this month. Please add a credit card on file to avoid dis­rup­tions to your ser­vice.

What we per­haps should have done at this point is stop and as­sess us­age. But in­stead we did as early-stage star­tups tend to do, and we… con­tin­ued cod­ing un­til some­thing stopped us.

A cou­ple weeks later we got a “You’ve spent $500.60 on Blacksmith this month” mes­sage, which did­n’t seem true since we were on the free trial still. Maybe that was what it would have cost if we weren’t on the trial? Anyhow, it was one of an em­bar­rass­ingly large num­ber of us­age-warn­ing emails in our in­boxes, and this one nei­ther had a credit card nor im­pacted pro­duc­tion users.

A cou­ple weeks later, we got in short suc­ces­sion an­other “Add a credit card to avoid dis­rup­tions” mes­sage, an in­voice for $1081, then two days later an over­due no­tice:

This is a re­minder from the Blacksmith fi­nance team that some in­voices are over­due. The to­tal amount due is $1,081.45. Our con­trac­tu­ally agreed pay­ment terms re­quire pay­ment upon in­voice gen­er­a­tion.

This is a re­minder from the Blacksmith fi­nance team that some in­voices are over­due.

The to­tal amount due is $1,081.45.

Our con­trac­tu­ally agreed pay­ment terms re­quire pay­ment upon in­voice gen­er­a­tion.

Interesting!

Now typ­i­cally, when you try a SaaS prod­uct for free with­out a credit card, and you hit the limit, you get cut off. Also known as “disruption to your ser­vice”. Instead, we were in­voiced $1000, which was im­me­di­ately over­due.

We asked for clar­i­fi­ca­tion, and Blacksmith sup­port in­formed us that the pre­vi­ous warn­ing of “disruption” was not that ser­vice would stop, but that it might be flagged for sus­pi­cious ac­tiv­ity.

The “disruption” word­ing in our re­minder email refers to ac­count flag­ging for re­view such as sus­pi­cious ac­tiv­ity and re­view for sus­pen­sion. There is no word­ing stat­ing au­to­matic sus­pen­sion of run­ning jobs as we know how im­pact­ful this can be to cus­tomers. We don’t cut work­flows when the free tier is ex­ceeded; they con­tinue run­ning and ac­crue us­age at the pub­lished rates.

The “disruption” word­ing in our re­minder email refers to ac­count flag­ging for re­view such as sus­pi­cious ac­tiv­ity and re­view for sus­pen­sion. There is no word­ing stat­ing au­to­matic sus­pen­sion of run­ning jobs as we know how im­pact­ful this can be to cus­tomers. We don’t cut work­flows when the free tier is ex­ceeded; they con­tinue run­ning and ac­crue us­age at the pub­lished rates.

And, well… this is true! They did­n’t ex­plic­itly say they’d stop run­ning jobs if we hit the end of the free limit. They did­n’t pre­cisely say that “try for free” and “no credit card re­quired” meant we would­n’t in­cur thou­sands of dol­lars of charges. That was all just… con­ven­tion.

This raises a few in­ter­est­ing ques­tions. To wit:

1. Can they?

Can a SaaS ven­dor like Blacksmith send an in­voice for a “try for free”, “no credit card” ser­vice that has ex­ceeded its limit, and ex­pect pay­ment?

While amus­ingly as of June 8 Blacksmith’s terms im­plied that their right to bill you is con­tin­gent on you pro­vid­ing pay­ment in­for­ma­tion, a SaaS app cer­tainly could have terms that ob­lig­ate users to pay for un­ex­pected over­age when on a free trial.

And let’s be clear: our agents run a lot of CI jobs, so we did ex­pect to hit the lim­its of the free plan. We used the ser­vice and got value for it. So it’s not in­her­ently dis­hon­est, just sur­pris­ing. My read is that they can do this.

2. Will cus­tomers be sur­prised?

What per­cent­age of users would ex­pect to get an in­voice for CI over­age on a “try for free”, “no credit card” ser­vice that has ex­ceeded its limit?

I’m pretty sure this is low. Sub 5% maybe?

You can try ask­ing a chat­bot whether Blacksmith would likely cut you off vs. in­voice for over­age, and the av­er­aged wis­dom of the in­ter­net will ar­gue pretty strongly that you’ll prob­a­bly get cut off — even if you don’t men­tion the email warn­ing you to add a credit card to pre­vent “disruption”. While of course this is ev­i­dence that chat­bots can of­ten be wrong, it’s also a hint that this pol­icy is un­usual.

Most users will ex­pect the free lim­its on a SaaS ser­vice to be a hard cap, at least un­til you’ve put in pay­ment in­for­ma­tion.

3. Should ser­vices do this?

You can imag­ine that let­ting free users go into over­age, then send­ing them over­due in­voices might make you more rev­enue than cut­ting them off. It’s not clear how much of this rev­enue you’d ac­tu­ally col­lect — surely your payables and write-offs would ex­plode — but all other things be­ing equal, it seems like it would in­crease rev­enue stats in the short term.

All things aren’t equal, of course. I think the clear an­swer is that this is a bad prac­tice.

Letting credit-card-less users roll into ac­cu­mu­lat­ing over­age cre­ates headaches for the ser­vice provider and the cus­tomers, and mostly ad­van­tages abu­sive users (who never in­tend to pay, and now get more free run­way). While this might juice short-term rev­enue stats, I’m highly skep­ti­cal the good­will and abuse costs are less than the ex­tra rev­enue.

I mean, maybe, if you think it’s un­fath­omable to cut off the free CI ser­vices you’ve pro­vi­sioned to a trial user, you could give them warn­ing — “Your CI ser­vices will be cut off in 72 hours if you don’t put in a credit card” or the like.

I can only spec­u­late why Blacksmith in­stead chose to in­voice in ar­rears. It could con­ceiv­ably be sketchy growth hack­ing, a mid­dle man­ager try­ing to hit a quar­terly rev­enue stat. It could be tech­ni­cal debt be­tween their billing sys­tems and pro­vi­sion­ing. And I sup­pose it could be the hot new trend among YC star­tups, try­ing to win share in a hot mar­ket.

But given Blacksmith’s nat­u­rally ex­plo­sive growth amidst the tire fire that is GitHub in spring 2026, my money is on sim­ple over­sight. Perhaps a de­ci­sion made un­der duress that they’ll soon fig­ure out is not for the best.

Their sup­port even­tu­ally said they “can look how to mit­i­gate this con­fu­sion in the fu­ture,” so that’s some­thing.

4. Should you use Blacksmith any­way?

This ques­tion is for us: will we keep us­ing Blacksmith, de­spite them giv­ing us an un­pleas­ant sur­prise and a prickly sup­port ex­change?

Well, we tried switch­ing back to GitHub Actions, and… yeah it still sucks. Blacksmith has grown ex­plo­sively be­cause it makes an in­creas­ingly frus­trat­ing bot­tle­neck in the dev cy­cle faster.

In the end, we’re prag­matic. Our love of mov­ing quickly ex­ceeds any grudges about sur­pris­ing billing poli­cies. Blacksmith helps us build faster, and once we agreed to pay for the (actually use­ful) ser­vice, their sup­port got friend­lier. So… we’ll prob­a­bly switch back.

But two tips for you, dear reader. First, if you build a SaaS ser­vice, be aware that most users will ex­pect their free ac­counts to pause be­fore ac­cu­mu­lat­ing over­age, and send­ing them in­voices is go­ing to be poorly re­ceived by many.

And sec­ond: if you’re go­ing to try Blacksmith, at least for the time be­ing, maybe wind it down be­fore you hit your trial limit.

Jun 10th, 2026 Lev Kokotov

Postgres is the only data­base you need.

The rea­son DBs like Mongo or Dynamo ex­ist is be­cause Postgres has a scal­ing prob­lem. If you could make it just work, with 100 TB+ ta­bles and 1M queries per sec­ond, we don’t think you would use any­thing else.

This is why we are build­ing PgDog. Same old Postgres, just with a proxy in front of it, to make it hor­i­zon­tally scal­able.

You can de­ploy PgDog any­where, in­clud­ing on-prem and in your cloud ac­count: pull our Docker im­age, change your DATABASE_URL, and make us do the work.

Our sta­tus

PgDog is serv­ing more than 2M queries per sec­ond, in pro­duc­tion, across dozens of de­ploy­ments. We sharded over 20 TB that we know about.

PgDog is open source and any­one can just de­ploy it, and they do: we have over 1.4M Docker pulls on GitHub.

A new ver­sion comes out every week, on Thursdays. Our Discord com­mu­nity is grow­ing. We are there, every day, to an­swer ques­tions and pro­vide sup­port.

Why us

PgDog is a small, three-per­son startup. So, why use our stuff and trust us with your data?

We are in­fra­struc­ture en­gi­neers, ap­pli­ca­tion en­gi­neers and gen­er­al­ists. We built apps on Postgres be­fore it was cool and made it work at mas­sive scale.

I ran Postgres at Instacart, where we scaled the com­pany 5x in April of 2020. The biggest prob­lem we had was mak­ing Postgres serve 100,000s of gro­cery de­liv­ery or­ders per minute.

We sharded Postgres on RDS, Aurora and EC2. We fixed the ac­tual prob­lem, us­ing first prin­ci­ples (and a lot of code).

The same tech­nol­ogy is now avail­able as an open source prod­uct.

Building PgDog is not a pivot. For us, scal­ing Postgres has been, and is, the only goal.

We built PgDog to run in your cloud, in your colo rack, on-prem, or on your lap­top. Wherever you need it, PgDog works, with no de­pen­den­cies or hid­den server­less costs. If you can pro­vide CPUs, our mul­ti­threaded code will use them all.

Postgres adop­tion is only go­ing to in­crease. With $5.5M from Basis Set, YC, Pioneer Fund and other great in­vestors, we have years of run­way, and we are go­ing to make Postgres just work, for every­one, at any scale.

– Lev

P.S. We are build­ing an Enterprise edi­tion of PgDog to make it eas­ier to run in AWS. It comes with SLA-backed sup­port from our team. Give us a call if you want to try it out.

More info

Read our docs to get started with PgDog

Star our repo and fol­low it for weekly re­leases

Join our Discord to get to know us bet­ter

Preflight Checklist

I have searched ex­ist­ing is­sues and this has­n’t been re­ported yet

This is a sin­gle bug re­port (please file sep­a­rate re­ports for dif­fer­ent bugs)

I am us­ing the lat­est ver­sion of Claude Code

What’s Wrong?

[BUG] Claude Desktop spawns 1.8 GB Hyper-V VM on every launch, even for chat-only use Environment

Note: This is­sue is spe­cific to the Claude Desktop app (Windows), not Claude Code CLI.

OS: Windows 11 Pro 25H2, Build 26200.7840 Hardware: Razer Blade 15 Base Model (Late 2020), i7 – 10750H, 16 GB RAM Claude Desktop: Latest ver­sion as of 2/26/2026 Windows Features: VirtualMachinePlatform en­abled; Hyper-V, WSL, Docker, and Windows Sandbox are all dis­abled Core Isolation / Memory Integrity: Off

Summary The Claude Desktop app launches a Hyper-V vir­tual ma­chine (Vmmem) con­sum­ing ap­prox­i­mately 1.8 GB of RAM every time it starts — even when the user only needs chat func­tion­al­ity and has no in­ten­tion of us­ing Cowork or agent mode. On a 16 GB lap­top, this rep­re­sents over 11% of to­tal mem­ory con­sumed by in­fra­struc­ture that is­n’t be­ing used. Steps to Reproduce

Install Claude Desktop on Windows 11 with VirtualMachinePlatform en­abled Use Cowork/agent mode at least once (this cre­ates ses­sion files) Close and re­open Claude Desktop — or sim­ply re­boot the ma­chine Open Task Manager and ob­serve Vmmem con­sum­ing ~1,800 MB

What Happens On every launch, the Claude Desktop app trig­gers the Hyper-V Host Compute Service (vmcompute) via an RPC in­ter­face event, which spawns a vmwp.exe process host­ing a full vir­tual ma­chine. This VM ap­pears as “Vmmem” in Task Manager at ap­prox­i­mately 1,796 – 1,846 MB. The Hyper-V Compute Admin event log shows re­peated er­rors: “The spec­i­fied prop­erty query is in­valid: The vir­tual ma­chine or con­tainer JSON doc­u­ment is in­valid. (0xC037010D, ‘Invalid JSON doc­u­ment ‘$’’)” These er­rors have been oc­cur­ring since at least 2/19/2026, trig­gered on every boot and app launch. Root Cause Investigation Through ex­ten­sive PowerShell di­ag­nos­tics, we con­firmed:

WSL is not in­stalled — wsl –shutdown re­turns “not in­stalled” Hyper-V man­age­ment tools are not in­stalled — Get-VM fails Docker is not in­stalled — no Docker processes found Windows Sandbox is dis­abled Core Isolation / Memory Integrity is off (and was off be­fore this is­sue started) VirtualizationBasedSecurityStatus shows 2 (running), likely due to LSA Protection be­ing en­abled — but this alone does­n’t ex­plain the 1.8 GB VM The only en­abled vir­tu­al­iza­tion fea­ture is VirtualMachinePlatform

The vm­com­pute ser­vice is set to Manual start but is trig­gered at boot by an RPC in­ter­face event (GUID: bc90d167 – 9470-4139-a9ba-be0bbbf5b74d). The par­ent process is ser­vices.exe (PID 1400), con­firm­ing it’s a ser­vice trig­ger, not a user-ini­ti­ated launch. We found 2,689 stale ses­sion files in %APPDATA%\Claude\local-agent-mode-sessions\ — all from pre­vi­ous Cowork ses­sions that were never cleaned up. Session names fol­low Docker-style nam­ing (e.g., “nifty-dreamy-volta”, “tender-vigilant-goodall”, “admiring-elegant-johnson”). Even af­ter delet­ing all 2,689 files and killing vm­com­pute/​vmwp, sim­ply re­open­ing the Claude Desktop app im­me­di­ately respawned the VM and the 1.8 GB Vmmem process. Impact On a 16 GB sys­tem, this bug causes mem­ory us­age to jump from ~50% to ~62% at idle be­fore the user does any­thing. Combined with nor­mal ap­pli­ca­tion load, this pushes to­tal us­age to 70 – 75%, caus­ing sys­tem slug­gish­ness and forc­ing the user to man­u­ally kill VM processes af­ter every launch. Expected Behavior

The Claude Desktop app should not spawn a VM for chat-only ses­sions If Cowork in­fra­struc­ture is needed, it should ini­tial­ize on de­mand — only when the user ac­tu­ally starts a Cowork/agent ses­sion Stale ses­sion files from pre­vi­ous Cowork ses­sions should be cleaned up au­to­mat­i­cally, not ac­cu­mu­late in­def­i­nitely (2,689 files in our case) The app should fall back to chat-only mode if VM ini­tial­iza­tion fails or is un­nec­es­sary, rather than un­con­di­tion­ally start­ing VM in­fra­struc­ture

Current Workaround The only re­li­able workaround is to dis­able VirtualMachinePlatform en­tirely: pow­er­shellD­is­able-Win­dow­sOp­tion­alFea­ture -Online -FeatureName “VirtualMachinePlatform” -NoRestart This pre­vents the VM from launch­ing but also dis­ables Cowork func­tion­al­ity. Alternatively, the user can kill the VM processes af­ter every launch: pow­er­shell­Stop-Process -Name vmwp -Force Stop-Process -Name vm­com­pute -Force Chat func­tion­al­ity con­tin­ues to work nor­mally af­ter killing these processes. Request Please mod­ify the Claude Desktop app so that:

VM/container in­fra­struc­ture only ini­tial­izes when Cowork or agent mode is ac­tively re­quested Old ses­sion data is cleaned up au­to­mat­i­cally af­ter ses­sions end The app grace­fully han­dles the ab­sence of VM in­fra­struc­ture with­out de­graded chat per­for­mance

What Should Happen?

The Claude Desktop app should not spawn a Hyper-V VM (Vmmem, ~1.8 GB RAM) when launch­ing for chat-only use. VM/container in­fra­struc­ture should only ini­tial­ize when the user ac­tively starts a Cowork or agent ses­sion. Stale ses­sion files should be cleaned up au­to­mat­i­cally af­ter ses­sions end.

Error Messages/Logs

Hyper-V Compute Admin log shows re­peated er­rors on every boot: “The spec­i­fied prop­erty query is in­valid: The vir­tual ma­chine or con­tainer JSON doc­u­ment is in­valid. (0xC037010D, ‘Invalid JSON doc­u­ment ‘$’’)”

Steps to Reproduce

Install Claude Desktop on Windows 11 with VirtualMachinePlatform en­abled

Use Cowork at least once

Close and re­open Claude Desktop (or re­boot)

Observe Vmmem in Task Manager con­sum­ing ~1,800 MB at 0% CPU

Claude Model

Not sure / Multiple mod­els

Is this a re­gres­sion?

I don’t know

Last Working Version

No re­sponse

Claude Code Version

Claude Desktop (Windows) lat­est as of 2/26/2026

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

See de­tailed bug re­port in de­scrip­tion above.