When we re­leased Claude Code, we ex­pected de­vel­op­ers to use it for cod­ing. They did—and then quickly be­gan us­ing it for al­most every­thing else. This prompted us to build Cowork: a sim­pler way for any­one—not just de­vel­op­ers—to work with Claude in the very same way. Cowork is avail­able to­day as a re­search pre­view for Claude Max sub­scribers on our ma­cOS app, and we will im­prove it rapidly from here.

How is us­ing Cowork dif­fer­ent from a reg­u­lar con­ver­sa­tion? In Cowork, you give Claude ac­cess to a folder of your choos­ing on your com­puter. Claude can then read, edit, or cre­ate files in that folder. It can, for ex­am­ple, re-or­ga­nize your down­loads by sort­ing and re­nam­ing each file, cre­ate a new spread­sheet with a list of ex­penses from a pile of screen­shots, or pro­duce a first draft of a re­port from your scat­tered notes.

In Cowork, Claude com­pletes work like this with much more agency than you’d see in a reg­u­lar con­ver­sa­tion. Once you’ve set it a task, Claude will make a plan and steadily com­plete it, while loop­ing you in on what it’s up to. If you’ve used Claude Code, this will feel fa­mil­iar—Cowork is built on the very same foun­da­tions. This means Cowork can take on many of the same tasks that Claude Code can han­dle, but in a more ap­proach­able form for non-cod­ing tasks.

When you’ve mas­tered the ba­sics, you can make Cowork more pow­er­ful still. Claude can use your ex­ist­ing con­nec­tors, which link Claude to ex­ter­nal in­for­ma­tion, and in Cowork we’ve added an ini­tial set of skills that im­prove Claude’s abil­ity to cre­ate doc­u­ments, pre­sen­ta­tions, and other files. If you pair Cowork with Claude in Chrome, Claude can com­plete tasks that re­quire browser ac­cess, too.

Cowork is de­signed to make us­ing Claude for new work as sim­ple as pos­si­ble. You don’t need to keep man­u­ally pro­vid­ing con­text or con­vert­ing Claude’s out­puts into the right for­mat. Nor do you have to wait for Claude to fin­ish be­fore of­fer­ing fur­ther ideas or feed­back: you can queue up tasks and let Claude work through them in par­al­lel. It feels much less like a back-and-forth and much more like leav­ing mes­sages for a coworker.

In Cowork, you can choose which fold­ers and con­nec­tors Claude can see: Claude can’t read or edit any­thing you don’t give it ex­plicit ac­cess to. Claude will also ask be­fore tak­ing any sig­nif­i­cant ac­tions, so you can steer or course-cor­rect it as you need.

That said, there are still things to be aware of be­fore you give Claude con­trol. By de­fault, the main thing to know is that Claude can take po­ten­tially de­struc­tive ac­tions (such as delet­ing lo­cal files) if it’s in­structed to. Since there’s al­ways some chance that Claude might mis­in­ter­pret your in­struc­tions, you should give Claude very clear guid­ance around things like this.

You should also be aware of the risk of “prompt in­jec­tions”: at­tempts by at­tack­ers to al­ter Claude’s plans through con­tent it might en­counter on the in­ter­net. We’ve built so­phis­ti­cated de­fenses against prompt in­jec­tions, but agent safety—that is, the task of se­cur­ing Claude’s real-world ac­tions—is still an ac­tive area of de­vel­op­ment in the in­dus­try.

These risks aren’t new with Cowork, but it might be the first time you’re us­ing a more ad­vanced tool that moves be­yond a sim­ple con­ver­sa­tion. We rec­om­mend tak­ing pre­cau­tions, par­tic­u­larly while you learn how it works. We pro­vide more de­tail in our Help Center.

This is a re­search pre­view. We’re re­leas­ing Cowork early be­cause we want to learn what peo­ple use it for, and how they think it could be bet­ter. We en­cour­age you to ex­per­i­ment with what Cowork can do for you, and to try things you don’t ex­pect to work: you might be sur­prised! As we learn more from this pre­view, we plan to make lots of im­prove­ments (including by adding cross-de­vice sync and bring­ing it to Windows), and we’ll iden­tify fur­ther ways to make it safer.

Claude Max sub­scribers can try Cowork now by down­load­ing the ma­cOS app, then click­ing on “Cowork” in the side­bar. If you’re on an­other plan, you can join the wait­list for fu­ture ac­cess.

Recently, I’ve been spend­ing my time build­ing an im­age-to-ASCII ren­derer. Below is the re­sult — try drag­ging it around, the demo is in­ter­ac­tive!

One thing I spent a lot of ef­fort on is get­ting edges look­ing sharp. Take a look at this ro­tat­ing cube ex­am­ple:

Try open­ing the “split” view. Notice how well the char­ac­ters fol­low the con­tour of the square.

This ren­derer works well for an­i­mated scenes, like the ones above, but we can also use it to ren­der sta­tic im­ages:

The im­age of Saturn was gen­er­ated with ChatGPT.

Then, to get bet­ter sep­a­ra­tion be­tween dif­fer­ent col­ored re­gions, I also im­ple­mented a cel shad­ing-like ef­fect to en­hance con­trast be­tween edges. Try drag­ging the con­trast slider be­low:

The con­trast en­hance­ment makes the sep­a­ra­tion be­tween dif­fer­ent col­ored re­gions far clearer. That was key to mak­ing the 3D scene above look as good as it does.

I put so much fo­cus on sharp edges be­cause they’re an as­pect of ASCII ren­der­ing that is of­ten over­looked when pro­gram­mat­i­cally ren­der­ing im­ages as ASCII. Consider this an­i­mated 3D scene from Cognition’s land­ing page that is ren­dered via ASCII char­ac­ters:

It’s a cool ef­fect, es­pe­cially while in mo­tion, but take a look at those blurry edges! The char­ac­ters fol­low the cube con­tours very poorly, and as a re­sult, the edges look blurry and jagged in places:

This blur­ri­ness hap­pens be­cause the ASCII char­ac­ters are be­ing treated like pix­els — their shape is ig­nored. It’s dis­ap­point­ing to see be­cause ASCII art looks so much bet­ter when shape is uti­lized. I don’t be­lieve I’ve ever seen shape uti­lized in gen­er­ated ASCII art, and I think that’s be­cause it’s not re­ally ob­vi­ous how to con­sider shape when build­ing an ASCII ren­derer.

I started build­ing my ASCII ren­derer to prove to my­self that it’s pos­si­ble to uti­lize shape in ASCII ren­der­ing. In this post, I’ll cover the tech­niques and ideas I used to cap­ture shape and build this ASCII ren­derer in de­tail.

We’ll start with the ba­sics of im­age-to-ASCII con­ver­sion and see where the com­mon is­sue of blurry edges comes from. After that, I’ll show you the ap­proach I used to fix that and achieve sharp, high-qual­ity ASCII ren­der­ing. At the end, we’ll im­prove on that by im­ple­ment­ing the con­trast en­hance­ment ef­fect I showed above.

Let’s get to it!

ASCII con­tains 95 print­able char­ac­ters that we can use. Let’s start off by ren­der­ing the fol­low­ing im­age con­tain­ing a white cir­cle us­ing those ASCII char­ac­ters:

ASCII art is (almost) al­ways ren­dered us­ing a mono­space font. Since every char­ac­ter in a mono­space font is equally wide and tall, we can split the im­age into a grid. Each grid cell will con­tain a sin­gle ASCII char­ac­ter.

The im­age with the cir­cle is pix­els. For the ASCII grid, I’ll pick a row height of pix­els and a col­umn width of pix­els. That splits the can­vas into rows and columns — an grid:

Monospace char­ac­ters are typ­i­cally taller than they are wide, so I made each grid cell a bit taller than it is wide.

Our task is now to pick which char­ac­ter to place in each cell. The sim­plest ap­proach is to cal­cu­late a light­ness value for each cell and pick a char­ac­ter based on that.

We can get a light­ness value for each cell by sam­pling the light­ness of the pixel at the cel­l’s cen­ter:

We want each pix­el’s light­ness as a nu­meric value be­tween and , but our im­age data con­sists of pix­els with RGB color val­ues.

We can use the fol­low­ing for­mula to con­vert an RGB color (with com­po­nent val­ues be­tween and ) to a light­ness value:

Now that we have a light­ness value for each cell, we want to use those val­ues to pick ASCII char­ac­ters. As men­tioned be­fore, ASCII has 95 print­able char­ac­ters, but let’s start sim­ple with just these char­ac­ters:

We can sort them in ap­prox­i­mate den­sity or­der like so, with lower-den­sity char­ac­ters to the left, and high-den­sity char­ac­ters to the right:

I added space as the first (least dense) char­ac­ter.

We can then map light­ness val­ues be­tween and to one of those char­ac­ters like so:

This maps low light­ness val­ues to low-den­sity char­ac­ters and high light­ness val­ues to high-den­sity char­ac­ters.

Rendering the cir­cle from above with this method gives us:

That works… but the re­sult is pretty ugly. We seem to al­ways get @ for cells that fall within the cir­cle and a space for cells that fall out­side.

That is hap­pen­ing be­cause we’ve pretty much just im­ple­mented near­est-neigh­bor down­sam­pling. Let’s see what that means.

Downsampling, in the con­text of im­age pro­cess­ing, is tak­ing a larger im­age (in our case, the im­age with the cir­cle) and us­ing that im­age’s data to con­struct a lower res­o­lu­tion im­age (in our case, the ASCII grid). The pixel val­ues of the lower res­o­lu­tion im­age are cal­cu­lated by sam­pling val­ues from the higher res­o­lu­tion im­age.

The sim­plest and fastest method of sam­pling is near­est-neigh­bor in­ter­po­la­tion, where, for each cell (pixel), we only take a sin­gle sam­ple from the higher res­o­lu­tion im­age.

Consider the cir­cle ex­am­ple again. Using near­est-neigh­bor in­ter­po­la­tion, every sam­ple ei­ther falls in­side or out­side of the shape, re­sult­ing in ei­ther or light­ness:

If, in­stead of pick­ing an ASCII char­ac­ter for each grid cell, we color each grid cell (pixel) ac­cord­ing to the sam­pled value, we get the fol­low­ing pix­e­lated ren­der­ing:

This pix­e­lated ren­der­ing is pretty much equiv­a­lent to the ASCII ren­der­ing from be­fore. The only dif­fer­ence is that in­stead of @s we have white pix­els, and in­stead of spaces we have black pix­els.

These square, jagged look­ing edges are alias­ing ar­ti­facts, com­monly called jag­gies. They’re a com­mon re­sult of us­ing near­est-neigh­bor in­ter­po­la­tion.

To get rid of jag­gies, we can col­lect more sam­ples for each cell. Consider this line:

The line’s slope on the axis is . When we pix­e­late it with near­est-neigh­bor in­ter­po­la­tion, we get the fol­low­ing:

Let’s try to get rid of the jag­gi­ness by tak­ing mul­ti­ple sam­ples within each cell and us­ing the av­er­age sam­pled light­ness value as the cel­l’s light­ness. The ex­am­ple be­low lets you vary the num­ber of sam­ples us­ing the slider:

With mul­ti­ple sam­ples, cells that lie on the edge of a shape will have some of their sam­ples fall within the shape, and some out­side of it. Averaging those, we get gray in-be­tween col­ors that smooth the down­sam­pled im­age. Below is the same ex­am­ple, but with an over­lay show­ing where the sam­ples are taken:

This method of col­lect­ing mul­ti­ple sam­ples from the larger im­age is called su­per­sam­pling. It’s a com­mon method of spa­tial anti-alias­ing (avoiding jag­gies at edges). Here’s what the ro­tat­ing square looks like with su­per­sam­pling (using sam­ples for each cell):

Let’s look at what su­per­sam­pling does for the cir­cle ex­am­ple from ear­lier. Try drag­ging the sam­ple qual­ity slider:

The cir­cle be­comes less jagged, but the edges feel blurry. Why’s that?

Well, they feel blurry be­cause we’re pretty much just ren­der­ing a low-res­o­lu­tion, pix­e­lated im­age of a cir­cle. Take a look at the pix­e­lated view:

The ASCII and pix­e­lated views are mir­ror im­ages of each other. Both are just low-res­o­lu­tion ver­sions of the orig­i­nal high-res­o­lu­tion im­age, scaled up to the orig­i­nal’s size — it’s no won­der they both look blurry.

Increasing the num­ber of sam­ples is in­suf­fi­cient. No mat­ter how many sam­ples we take per cell, the sam­ples will be av­er­aged into a sin­gle light­ness value, used to ren­der a sin­gle pixel.

And that’s the core prob­lem: treat­ing each grid cell as a pixel in an im­age. It’s an ob­vi­ous and sim­ple method, but it dis­re­gards that ASCII char­ac­ters have shape.

We can make our ASCII ren­der­ings far more crisp by pick­ing char­ac­ters based on their shape. Here’s the cir­cle ren­dered that way:

The char­ac­ters fol­low the con­tour of the cir­cle very well. By pick­ing char­ac­ters based on shape, we get a far higher ef­fec­tive res­o­lu­tion. The re­sult is also more vi­su­ally in­ter­est­ing.

Let’s see how we can im­ple­ment this.

So what do I mean by shape? Well, con­sider the char­ac­ters T, L, and O placed within grid cells:

The char­ac­ter T is top-heavy. Its vi­sual den­sity in the up­per half of the grid cell is higher than in the lower half. The op­po­site can be said for L — it’s bot­tom-heavy. O is pretty much equally dense in the up­per and lower halves of the cell.

We might also com­pare char­ac­ters like L and J. The char­ac­ter L is heav­ier within the left half of the cell, while J is heav­ier in the right half:

We also have more “extreme” char­ac­ters, such as _ and ^, that only oc­cupy the lower or up­per por­tion of the cell, re­spec­tively:

This is, roughly, what I mean by “shape” in the con­text of ASCII ren­der­ing. Shape refers to which re­gions of a cell a given char­ac­ter vi­su­ally oc­cu­pies.

To pick char­ac­ters based on their shape, we’ll some­how need to quan­tify (put num­bers to) the shape of each char­ac­ter.

Let’s start by only con­sid­er­ing how much char­ac­ters oc­cupy the up­per and lower re­gions of our cell. To do that, we’ll de­fine two “sampling cir­cles” for each grid cell — one placed in the up­per half and one in the lower half:

It may seem odd or ar­bi­trary to use cir­cles in­stead of just split­ting the cell into two rec­tan­gles, but us­ing cir­cles will give us more flex­i­bil­ity later on.

A char­ac­ter placed within a cell will over­lap each of the cel­l’s sam­pling cir­cles to some ex­tent.

One can com­pute that over­lap by tak­ing a bunch of sam­ples within the cir­cle (for ex­am­ple, at every pixel). The frac­tion of sam­ples that land in­side the char­ac­ter gives us the over­lap as a nu­meric value be­tween and :

For T, we get an over­lap of ap­prox­i­mately for the up­per cir­cle and for the lower. Those over­lap val­ues form a -dimensional vec­tor:

We can gen­er­ate such a -dimensional vec­tor for each char­ac­ter within the ASCII al­pha­bet. These vec­tors quan­tify the shape of each ASCII char­ac­ter along these di­men­sions (upper and lower). I’ll call these vec­tors shape vec­tors.

Below are some ASCII char­ac­ters and their shape vec­tors. I’m col­or­ing the sam­pling cir­cles us­ing the com­po­nent val­ues of the shape vec­tors:

We can use the shape vec­tors as 2D co­or­di­nates — here’s every ASCII char­ac­ter on a 2D plot:

Let’s say that we have our ASCII char­ac­ters and their as­so­ci­ated shape vec­tors in a CHARACTERS ar­ray:

We can then per­form a near­est neigh­bor search like so:

The find­BestChar­ac­ter func­tion gives us the ASCII char­ac­ter whose shape best matches the in­put lookup vec­tor.

Note: this brute force search is not very per­for­mant. This be­comes a bot­tle­neck when we start ren­der­ing thou­sands of ASCII char­ac­ters at  . I’ll talk more about this later.

To make use of this in our ASCII ren­derer, we’ll cal­cu­late a lookup vec­tor for each cell in the ASCII grid and pass it to find­BestChar­ac­ter to de­ter­mine the char­ac­ter to dis­play.

Let’s try it out. Consider the fol­low­ing zoomed-in cir­cle as an ex­am­ple. It is split into three grid cells:

Overlaying our sam­pling cir­cles, we see vary­ing de­grees of over­lap:

When cal­cu­lat­ing the shape vec­tor of each ASCII char­ac­ter, we took a huge num­ber of sam­ples. We could af­ford to do that be­cause we only need to cal­cu­late those shape vec­tors once up front. After they’re cal­cu­lated, we can use them again and again.

However, if we’re con­vert­ing an an­i­mated im­age (e.g. can­vas or video) to ASCII, we need to be mind­ful of per­for­mance when cal­cu­lat­ing the lookup vec­tors. An ASCII ren­der­ing might have hun­dreds or thou­sands of cells. Multiplying that by tens or hun­dreds of sam­ples would be in­cred­i­bly costly in terms of per­for­mance.

With that be­ing said, let’s pick a sam­pling qual­ity of with the sam­ples placed like so:

For the top sam­pling cir­cle of the left­most cell, we get one white sam­ple and two black, giv­ing us an av­er­age light­ness of . Doing the same cal­cu­la­tion for all of the sam­pling cir­cles, we get the fol­low­ing 2D vec­tors:

From now on, in­stead of us­ing the term “lookup vec­tors”, I’ll call these vec­tors, sam­pled from the im­age that we’re ren­der­ing as ASCII, sam­pling vec­tors. One sam­pling vec­tor is cal­cu­lated for each cell in the grid.

Anyway, we can use these sam­pling vec­tors to find the best-match­ing ASCII char­ac­ter. Let’s see what that looks like on our 2D plot — I’ll la­bel the sam­pling vec­tors (from left to right) C0, C1, and C2:

Hmm… this is not what we want. Since none of the ASCII shape vec­tor com­po­nents ex­ceed , they’re all clus­tered to­wards the bot­tom-left re­gion of our plot. This makes our sam­pling vec­tors map to a few char­ac­ters on the edge of the clus­ter.

We can fix this by nor­mal­iz­ing the shape vec­tors. We’ll do that by tak­ing the max­i­mum value of each com­po­nent across all shape vec­tors, and di­vid­ing the com­po­nents of each shape vec­tor by the max­i­mum. Expressed in code, that looks like so:

Here’s what the plot looks like with the shape vec­tors nor­mal­ized:

If we now map the sam­pling vec­tors to their near­est neigh­bors, we get a much more sen­si­ble re­sult:

We get ’, M and $. Let’s see how well those char­ac­ters match the cir­cle:

Nice! They match very well.

Let’s try ren­der­ing the full cir­cle from be­fore with the same method:

Much bet­ter than be­fore! The picked char­ac­ters fol­low the con­tour of the cir­cle very well.

Using two sam­pling cir­cles — one up­per and one lower — pro­duces a much bet­ter re­sult than the -dimensional (pixelated) ap­proach. However, it still falls short when try­ing to cap­ture other as­pects of a char­ac­ter’s shape.

For ex­am­ple, two cir­cles don’t cap­ture the shape of char­ac­ters that fall in the mid­dle of the cell. Consider -:

For -, we get a shape vec­tor of . That does­n’t rep­re­sent the char­ac­ter very well at all.

The two up­per-lower sam­pling cir­cles also don’t cap­ture left-right dif­fer­ences, such as the dif­fer­ence be­tween p and q:

We could use such dif­fer­ences to get bet­ter char­ac­ter picks, but our two sam­pling cir­cles don’t cap­ture them. Let’s add more di­men­sions to our shape to fix that.

Since cells are taller than they are wide (at least with the mono­space font I’m us­ing), we can use sam­pling cir­cles to cover the area of each cell quite well:

sam­pling cir­cles cap­ture left-right dif­fer­ences, such as be­tween p and q, while also cap­tur­ing dif­fer­ences across the top, bot­tom, and mid­dle re­gions of the cell, dif­fer­en­ti­at­ing ^, -, and _. They also cap­ture the shape of “diagonal” char­ac­ters like / to a rea­son­able de­gree.

One prob­lem with this grid-like con­fig­u­ra­tion for the sam­pling cir­cles is that there are gaps. For ex­am­ple, . falls be­tween the sam­pling cir­cles:

To com­pen­sate for this, we can stag­ger the sam­pling cir­cles ver­ti­cally (e.g. low­er­ing the left sam­pling cir­cles and rais­ing the right ones) and make them a bit larger. This causes the cell to be al­most fully cov­ered while not caus­ing ex­ces­sive over­lap across the sam­pling cir­cles:

We can use the same pro­ce­dure as be­fore to gen­er­ate char­ac­ter vec­tors us­ing these sam­pling cir­cles, this time yield­ing a -dimensional vec­tor. Consider the char­ac­ter L:

For L, we get the vec­tor:

I’m pre­sent­ing -dimensional shape vec­tors in a ma­trix form be­cause it’s eas­ier to grok geo­met­ri­cally, but the ac­tual vec­tor is a flat list of num­bers.

The light­ness val­ues cer­tainly look L-shaped! The 6D shape vec­tor cap­tures L’s shape very well.

Now we have a 6D shape vec­tor for every ASCII char­ac­ter. Does that af­fect char­ac­ter lookups (how we find the best match­ing char­ac­ter)?

Earlier, in the find­BestChar­ac­ter func­tion, I ref­er­enced a get­Dis­tance func­tion. That func­tion re­turns the Euclidean dis­tance be­tween the in­put points. Given two 2D points and , the for­mula to cal­cu­late their Euclidean dis­tance looks like so:

Put into code, this looks like so:

Apple is join­ing forces with Google to power its ar­ti­fi­cial in­tel­li­gence fea­tures, in­clud­ing a ma­jor Siri up­grade ex­pected later this year.

The mul­ti­year part­ner­ship will lean on Google’s Gemini and cloud tech­nol­ogy for fu­ture Apple foun­da­tional mod­els, ac­cord­ing to a joint state­ment ob­tained by CNBC’s Jim Cramer.

“After care­ful eval­u­a­tion, we de­ter­mined that Google’s tech­nol­ogy pro­vides the most ca­pa­ble foun­da­tion for Apple Foundation Models and we’re ex­cited about the in­no­v­a­tive new ex­pe­ri­ences it will un­lock for our users,” Apple said in a state­ment Monday.

The mod­els will con­tinue to run on Apple de­vices and the com­pa­ny’s pri­vate cloud com­pute, the com­pa­nies added.

Apple de­clined to com­ment on the terms of the deal. Google re­ferred CNBC to the joint state­ment.

In August, Bloomberg re­ported that Apple was in early talks with Google to use a cus­tom Gemini model to power a new it­er­a­tion of Siri. The news out­let later re­ported that Apple was plan­ning to pay about $1 bil­lion a year to uti­lize Google AI.

The deal is an­other ma­jor in­di­ca­tor of grow­ing trust in Google’s ac­cel­er­at­ing AI agenda and come­back against OpenAI. In 2025, the search gi­ant logged its best year since 2009 and sur­passed Apple in mar­ket cap­i­tal­iza­tion last week for the first time since 2019.

Google al­ready pays Apple bil­lions each year to be the de­fault search en­gine on iPhones. But that lu­cra­tive part­ner­ship briefly came into ques­tion af­ter Google was found to hold an il­le­gal in­ter­net search mo­nop­oly.

In September, a judge ruled against a worst-case sce­nario out­come that could have forced Google to di­vest its Chrome browser busi­ness.

The de­ci­sion also al­lowed Google to con­tinue to make deals such as the one with Apple.

i was at bom­bay air­port. some dude was watch­ing reels on full vol­ume and laugh­ing loudly. ask­ing nicely does­n’t work any­more. me be­ing me, did­n’t have the courage to speak up.

so i built a tiny app that plays back the same au­dio it hears, de­layed by ~2 sec­onds. asked claude, it spat out a work­ing ver­sion in one prompt. sur­pris­ingly WORKS.

some­thing some­thing au­di­tory feed­back loop some­thing some­thing cog­ni­tive dis­so­nance. idk i’m not a neu­ro­sci­en­tist. all i know is it makes peo­ple shut up and that’s good enough for me.

straight up hon­est - orig­i­nally called this “make-it-stop” but then saw @TimDarcet also built sim­i­lar and named it STFU. wayyyyy bet­ter name. so stole it. sorry not sorry.

made with spite and web au­dio api. do what­ever you want with it.

yo, mean­while if you are new here, you might find my, other side pro­jects kinda funny.

The FBI raided the home of a Washington Post re­porter early on Wednesday in what the news­pa­per called a “highly un­usual and ag­gres­sive” move by law en­force­ment, and press free­dom groups con­demned as a “tremendous in­tru­sion” by the Trump ad­min­is­tra­tion.

Agents de­scended on the Virginia home of Hannah Natanson as part of an in­ves­ti­ga­tion into a gov­ern­ment con­trac­tor ac­cused of il­le­gally re­tain­ing clas­si­fied gov­ern­ment ma­te­ri­als.

An email sent on Wednesday af­ter­noon to Post staff from the ex­ec­u­tive ed­i­tor, Matt Murray, ob­tained by the Guardian, said agents turned up “unannounced”, searched her home and seized elec­tronic de­vices.

“This ex­tra­or­di­nary, ag­gres­sive ac­tion is deeply con­cern­ing and raises pro­found ques­tions and con­cern around the con­sti­tu­tional pro­tec­tions for our work,” the email said.

“The Washington Post has a long his­tory of zeal­ous sup­port for ro­bust press free­doms. The en­tire in­sti­tu­tion stands by those free­doms and our work.”

“It’s a clear and ap­palling sign that this ad­min­is­tra­tion will set no lim­its on its acts of ag­gres­sion against an in­de­pen­dent press,” Marty Baron, the Post’s for­mer ex­ec­u­tive ed­i­tor, told the Guardian.

Murray said nei­ther the news­pa­per nor Natanson were told they were the tar­get of a jus­tice de­part­ment in­ves­ti­ga­tion.

Pam Bondi, the at­tor­ney gen­eral, said in a post on X that the raid was con­ducted by the jus­tice de­part­ment and FBI at the re­quest of the Pentagon.

The war­rant, she said, was ex­e­cuted “at the home of a Washington Post jour­nal­ist who was ob­tain­ing and re­port­ing clas­si­fied and il­le­gally leaked in­for­ma­tion from a Pentagon con­trac­tor. The leaker is cur­rently be­hind bars.”

The state­ment gave no fur­ther de­tails of the raid or in­ves­ti­ga­tion. Bondi added: “The Trump ad­min­is­tra­tion will not tol­er­ate il­le­gal leaks of clas­si­fied in­for­ma­tion that, when re­ported, pose a grave risk to our na­tion’s na­tional se­cu­rity and the brave men and women who are serv­ing our coun­try.”

The re­porter’s home and de­vices were searched, and her Garmin watch, phone, and two lap­top com­put­ers, one be­long­ing to her em­ployer, were seized, the news­pa­per said. It added that agents told Natanson she was not the fo­cus of the in­ves­ti­ga­tion, and was not ac­cused of any wrong­do­ing.

A war­rant ob­tained by the Post cited an in­ves­ti­ga­tion into Aurelio Perez-Lugones, a sys­tem ad­min­is­tra­tor in Maryland with a top se­cret se­cu­rity clear­ance who has been ac­cused of ac­cess­ing and tak­ing home clas­si­fied in­tel­li­gence re­ports.

Natanson, the Post said, cov­ers the fed­eral work­force and has been a part of the news­pa­per’s “most high-pro­file and sen­si­tive cov­er­age” dur­ing the first year of the sec­ond Trump ad­min­is­tra­tion.

As the pa­per noted in its re­port, it is “highly un­usual and ag­gres­sive for law en­force­ment to con­duct a search on a re­porter’s home”.

In a first-per­son ac­count pub­lished last month, Natanson de­scribed her­self as the Post’s “federal gov­ern­ment whis­perer”, and said she would re­ceive calls day and night from “federal work­ers who wanted to tell me how President Donald Trump was rewrit­ing their work­place poli­cies, fir­ing their col­leagues or trans­form­ing their agen­cy’s mis­sions”.

“It’s been bru­tal,” the ar­ti­cle’s head­line said.

Natanson said her work had led to 1,169 new sources, “all cur­rent or for­mer fed­eral em­ploy­ees who de­cided to trust me with their sto­ries”. She said she learned in­for­ma­tion “people in­side gov­ern­ment agen­cies weren’t sup­posed to tell me”, say­ing that the in­ten­sity of the work nearly “broke” her.

The fed­eral in­ves­ti­ga­tion into Perez-Lugones, the Post said, in­volved doc­u­ments found in his lunch­box and his base­ment, ac­cord­ing to an FBI af­fi­davit. The crim­i­nal com­plaint against him does not ac­cuse him of leak­ing clas­si­fied in­for­ma­tion, the news­pa­per said.

Press free­dom groups were united in their con­dem­na­tion of the raid on Wednesday.

“Physical searches of re­porters’ de­vices, homes and be­long­ings are some of the most in­va­sive in­ves­tiga­tive steps law en­force­ment can take,” Bruce D Brown, pres­i­dent of the Reporters’ Committee for Freedom of the Press, said in a state­ment.

“There are spe­cific fed­eral laws and poli­cies at the Department of Justice that are meant to limit searches to the most ex­treme cases be­cause they en­dan­ger con­fi­den­tial sources far be­yond just one in­ves­ti­ga­tion and im­pair pub­lic in­ter­est re­port­ing in gen­eral.

“While we won’t know the gov­ern­men­t’s ar­gu­ments about over­com­ing these very steep hur­dles un­til the af­fi­davit is made pub­lic, this is a tremen­dous es­ca­la­tion in the ad­min­is­tra­tion’s in­tru­sions into the in­de­pen­dence of the press.”

Jameel Jaffer, ex­ec­u­tive di­rec­tor of the Knight First Amendment Institute, de­manded a pub­lic ex­pla­na­tion from the jus­tice de­part­ment of “why it be­lieves this search was nec­es­sary and legally per­mis­si­ble”.

In a state­ment, Jaffer said: “Any search tar­get­ing a jour­nal­ist war­rants in­tense scrutiny be­cause these kinds of searches can de­ter and im­pede re­port­ing that is vi­tal to our democ­racy.

“Attorney General Bondi has weak­ened guide­lines that were in­tended to pro­tect the free­dom of the press, but there are still im­por­tant le­gal lim­its, in­clud­ing con­sti­tu­tional ones, on the gov­ern­men­t’s au­thor­ity to use sub­poe­nas, court or­ders, and search war­rants to ob­tain in­for­ma­tion from jour­nal­ists.

“Searches of news­rooms and jour­nal­ists are hall­marks of il­lib­eral regimes, and we must en­sure that these prac­tices are not nor­mal­ized here.”

Seth Stern, chief of ad­vo­cacy for the Freedom of the Press Foundation, said it was “an alarm­ing es­ca­la­tion in the Trump ad­min­is­tra­tion’s mul­ti­pronged war on press free­dom” and called the war­rant “outrageous”.

“The ad­min­is­tra­tion may now be in pos­ses­sion of vol­umes of jour­nal­ist com­mu­ni­ca­tions hav­ing noth­ing to do with any pend­ing in­ves­ti­ga­tion and, if in­ves­ti­ga­tors are able to ac­cess them, we have zero faith that they will re­spect jour­nal­ist-source con­fi­den­tial­ity,” he said.

Tim Richardson, jour­nal­ism and dis­in­for­ma­tion pro­gram di­rec­tor at PEN America, said: “A gov­ern­ment ac­tion this rare and ag­gres­sive sig­nals a grow­ing as­sault on in­de­pen­dent re­port­ing and un­der­mines the First Amendment.

“It is in­tended to in­tim­i­date sources and chill jour­nal­ists’ abil­ity to gather news and hold the gov­ern­ment ac­count­able. Such be­hav­ior is more com­monly as­so­ci­ated with au­thor­i­tar­ian po­lice states than de­mo­c­ra­tic so­ci­eties that rec­og­nize jour­nal­is­m’s es­sen­tial role in in­form­ing the pub­lic.”

The Post has had a rocky re­la­tion­ship with the Trump ad­min­is­tra­tion in re­cent months, de­spite its bil­lion­aire owner, Jeff Bezos, the Amazon founder, at­tempt­ing to curry fa­vor by block­ing it from en­dors­ing Kamala Harris, the Democratic nom­i­nee, in the 2024 pres­i­den­tial elec­tion.

Bezos de­fended the ac­tion, which saw the de­ser­tion of more than 200,000 sub­scribers in protest.

The Astro Technology Company — the com­pany be­hind the Astro web frame­work — is join­ing Cloudflare! Adoption of the Astro web frame­work con­tin­ues to dou­ble every year, and Astro 6 is right around the cor­ner. With Cloudflare’s sup­port, we’ll have more re­sources and fewer dis­trac­tions to con­tinue our mis­sion to build the best frame­work for con­tent-dri­ven web­sites.

What this means for Astro:

* Astro con­tin­ues to sup­port a wide set of de­ploy­ment tar­gets, not just Cloudflare

* All full-time em­ploy­ees of The Astro Technology Company are now em­ploy­ees of Cloudflare, and will con­tinue to work on Astro full-time.

In 2021, Astro was born out of frus­tra­tion. The trend at the time was that every web­site should be ar­chi­tected as an ap­pli­ca­tion, and then shipped to the user’s browser to ren­der. This was not very per­for­mant, and we’ve spent the last decade com­ing up with more and more com­plex so­lu­tions to solve for that per­for­mance prob­lem. SSR, ISR, RSC, PPR, TTI op­ti­miza­tions via code-split­ting, tree-shak­ing, lazy-load­ing, all to gen­er­ate a block­ing dou­ble-data hy­dra­tion pay­load from a pre-warmed server run­ning halfway around the world.

Our mis­sion to de­sign a web frame­work specif­i­cally for build­ing web­sites — what we call con­tent-dri­ven web­sites, to bet­ter dis­tin­guish from data-dri­ven, state­ful web ap­pli­ca­tions — res­onated. Now Astro is down­loaded al­most 1,000,000 times per week, and has been used by 100,000s of de­vel­op­ers to build fast, beau­ti­ful web­sites. Today you’ll find Astro all over the web, pow­er­ing ma­jor web­sites and even en­tire de­vel­oper plat­forms for com­pa­nies like Webflow, Wix, Microsoft, and Google.

Along the way, we also tried to grow a busi­ness. In 2021 we raised some money and formed The Astro Technology Company. Our larger vi­sion was that a well-de­signed frame­work like Astro could sit at the cen­ter of a mas­sive de­vel­oper plat­form, with op­tional hosted prim­i­tives (database, stor­age, an­a­lyt­ics) de­signed in lock­step with the frame­work.

We were never able to re­al­ize this vi­sion. Attempts to in­tro­duce paid, hosted prim­i­tives into our ecosys­tem fell flat, and rarely jus­ti­fied their own ex­is­tence. We con­sid­ered go­ing more di­rectly af­ter first-class host­ing or con­tent man­age­ment for Astro, but knew we’d spend much of our time play­ing catchup to well-funded, savvy com­peti­tors. We kept ex­plor­ing dif­fer­ent ideas, but noth­ing clicked with users the same way Astro did.

It was­n’t all bad. Astro DB (our at­tempt to build a hosted data­base prod­uct for Astro pro­jects) even­tu­ally evolved into the open, built-in Astro data­base client that still lives in core to­day. Our ex­plo­ration into build­ing an e-com­merce layer with Astro was even­tu­ally open-sourced. It was re­ward­ing work, but over the years the dis­trac­tion took its toll. Each at­tempt at a new paid prod­uct or of­fer­ing took my­self and oth­ers on the pro­ject away from work­ing on the Astro frame­work that de­vel­op­ers were us­ing and lov­ing every day.

Last year, Dane (Cloudflare CTO) and I be­gan to talk more se­ri­ously about the fu­ture of the web. Those con­ver­sa­tions quickly grew into some­thing big­ger: What does the next decade look like? How do frame­works adapt to a world of AI cod­ing and agents?

It be­came clear that even as web tech­nolo­gies evolve, con­tent re­mains at the cen­ter. We re­al­ized that we’ve each been work­ing to­ward this same vi­sion from dif­fer­ent an­gles:

* Cloudflare has been solv­ing it from the in­fra­struc­ture side: bet­ting on a plat­form that is global by de­fault, with fast startup, low la­tency, and se­cu­rity built-in.

* Astro has been solv­ing it from the frame­work side: bet­ting on a web frame­work that makes it easy to build sites that are fast by de­fault, with­out over­com­pli­cat­ing things.

The over­lap is ob­vi­ous. By work­ing to­gether, Cloudflare gives us the back­ing we need to keep in­no­vat­ing for our users. Now we can stop spend­ing cy­cles wor­ry­ing about build­ing a busi­ness on top of Astro, and start fo­cus­ing 100% on the code, with a shared vi­sion to move the web for­ward.

Cloudflare has been a long-time spon­sor and cham­pion of Astro. They have a proven track record of sup­port­ing great open-source pro­jects like Astro, TanStack, and Hono with­out try­ing to cap­ture or lock any­thing down. Staying open to all was a non-ne­go­tiable re­quire­ment for both us and for Cloudflare.

That is why Astro will re­main free, open-source, and MIT-licensed. We will con­tinue to run our pro­ject in the open, with an open gov­er­nance model for con­trib­u­tors and an open com­mu­nity roadmap that any­one can par­tic­i­pate in. We re­main fully com­mit­ted to main­tain­ing Astro as a plat­form-ag­nos­tic frame­work, mean­ing we will con­tinue to sup­port and im­prove de­ploy­ments for all tar­gets—not just Cloudflare.

With Cloudflare’s re­sources and sup­port, we can now re­turn our fo­cus fully to­wards build­ing the best web frame­work for con­tent-dri­ven web­sites. The web is chang­ing fast, and the bar keeps ris­ing: per­for­mance, scale, re­li­a­bil­ity, and a bet­ter ex­pe­ri­ence for the teams ship­ping con­tent on the web.

You’ll see that fo­cus re­flected across our roadmap, as we pre­pare for the up­com­ing Astro 6 re­lease (beta out now!) and our 2026 roadmap. Stay tuned!

I want to ex­tend a huge thank you to the agen­cies, com­pa­nies, spon­sors, part­ners, and theme au­thors who chose to work with us over the years. Thank you to our ini­tial in­vestors — Haystack, Gradient, Uncorrelated, Lightspeed — with­out whom Astro likely would­n’t ex­ist. Thank you to every­one in our open source com­mu­nity who con­tin­ues to help make Astro bet­ter every day. And fi­nally, thank you to every­one who uses Astro and puts their trust in us to help them build for the web.

Two days ago, Anthropic re­leased the Claude Cowork re­search pre­view (a gen­eral-pur­pose AI agent to help any­one with their day-to-day work). In this ar­ti­cle, we demon­strate how at­tack­ers can ex­fil­trate user files from Cowork by ex­ploit­ing an un­re­me­di­ated vul­ner­a­bil­ity in Claude’s cod­ing en­vi­ron­ment, which now ex­tends to Cowork. The vul­ner­a­bil­ity was first iden­ti­fied in Claude.ai chat be­fore Cowork ex­isted by Johann Rehberger, who dis­closed the vul­ner­a­bil­ity — it was ac­knowl­edged but not re­me­di­ated by Anthropic.

Anthropic warns users, “Cowork is a re­search pre­view with unique risks due to its agen­tic na­ture and in­ter­net ac­cess.” Users are rec­om­mended to be aware of “suspicious ac­tions that may in­di­cate prompt in­jec­tion”. However, as this fea­ture is in­tended for use by the gen­eral pop­u­lace, not just tech­ni­cal users, we agree with Simon Willison’s take:

“I do not think it is fair to tell reg­u­lar non-pro­gram­mer users to watch out for ‘suspicious ac­tions that may in­di­cate prompt in­jec­tion’!”

As Anthropic has ac­knowl­edged this risk and put it on users to “avoid grant­ing ac­cess to lo­cal files with sen­si­tive in­for­ma­tion” (while si­mul­ta­ne­ously en­cour­ag­ing the use of Cowork to or­ga­nize your Desktop), we have cho­sen to pub­licly dis­close this demon­stra­tion of a threat users should be aware of. By rais­ing aware­ness, we hope to en­able users to bet­ter iden­tify the types of ‘suspicious ac­tions’ men­tioned in Anthropic’s warn­ing.

This at­tack lever­ages the al­lowlist­ing of the Anthropic API to achieve data egress from Claude’s VM en­vi­ron­ment (which re­stricts most net­work ac­cess).

The vic­tim con­nects Cowork to a lo­cal folder con­tain­ing con­fi­den­tial real es­tate files­The vic­tim up­loads a file to Claude that con­tains a hid­den prompt in­jec­tion

For gen­eral use cases, this is quite com­mon; a user finds a file on­line that they up­load to Claude code. This at­tack is not de­pen­dent on the in­jec­tion source - other in­jec­tion sources in­clude, but are not lim­ited to: web data from Claude for Chrome, con­nected MCP servers, etc. In this case, the at­tack has the file be­ing a Claude ‘Skill’ (although, as men­tioned, it could also just be a reg­u­lar doc­u­ment), as it is a gen­er­al­iz­able file con­ven­tion that users are likely to en­counter, es­pe­cially when us­ing Claude.

Note: If you are fa­mil­iar with Skills, they are canon­i­cally Markdown files (which users of­ten do not heav­ily scru­ti­nize). However, we demon­strate some­thing more in­ter­est­ing: here, the user up­loads a .docx (such as may be shared on an on­line fo­rum), which poses as a Skill - the con­tents ap­pear to be Markdown that was just saved af­ter edit­ing in Word. In re­al­ity, this trick al­lows at­tack­ers to con­ceal the in­jec­tion us­ing 1-point font, white-on-white text, and with line spac­ing set to 0.1 — mak­ing it ef­fec­tively im­pos­si­ble to de­tect. The vic­tim asks Cowork to an­a­lyze their files us­ing the Real Estate ‘skill’ they up­load­edThe in­jec­tion ma­nip­u­lates Cowork to up­load files to the at­tack­er’s Anthropic ac­count

The in­jec­tion tells Claude to use a ‘curl’ com­mand to make a re­quest to the Anthropic file up­load API with the largest avail­able file. The in­jec­tion then pro­vides the at­tack­er’s API key, so the file will be up­loaded to the at­tack­er’s ac­count.

At no point in this process is hu­man ap­proval re­quired.If we ex­pand the ‘Running com­mand’ block, we can see the ma­li­cious re­quest in de­tail:Code ex­e­cuted by Claude is run in a VM - re­strict­ing out­bound net­work re­quests to al­most all do­mains - but the Anthropic API flies un­der the radar as trusted, al­low­ing this at­tack to com­plete suc­cess­fully. The at­tack­er’s ac­count con­tains the vic­tim’s file, al­low­ing them to chat with it­The ex­fil­trated file con­tains fi­nan­cial fig­ures and PII, in­clud­ing par­tial SSNs.

The above ex­ploit was demon­strated against Claude Haiku. Although Claude Opus 4.5 is known to be more re­silient against in­jec­tions, Opus 4.5 in Cowork was suc­cess­fully ma­nip­u­lated via in­di­rect prompt in­jec­tion to lever­age the same file up­load vul­ner­a­bil­ity to ex­fil­trate data in a test that con­sid­ered a ‘user’ up­load­ing a ma­li­cious in­te­gra­tion guide while de­vel­op­ing a new AI tool:

As the fo­cus of this ar­ti­cle was more for every­day users (and not de­vel­op­ers), we opted to demon­strate the above at­tack chain in­stead of this one.

An in­ter­est­ing find­ing: Claude’s API strug­gles when a file does not match the type it claims to be. When op­er­at­ing on a mal­formed PDF (ends .pdf, but it is re­ally a text file with a few sen­tences in it), af­ter try­ing to read it once, Claude starts throw­ing an API er­ror in every sub­se­quent chat in the con­ver­sa­tion.

We posit that it is likely pos­si­ble to ex­ploit this fail­ure via in­di­rect prompt in­jec­tion to cause a lim­ited de­nial of ser­vice at­tack (e.g., an in­jec­tion can elicit Claude to cre­ate a mal­formed file, and then read it). Uploading the mal­formed file via the files API re­sulted in no­ti­fi­ca­tions with an er­ror mes­sage, both in the Claude client and the Anthropic Console.

One of the key ca­pa­bil­i­ties that Cowork was cre­ated for is the abil­ity to in­ter­act with one’s en­tire day-to-day work en­vi­ron­ment. This in­cludes the browser and MCP servers, grant­ing ca­pa­bil­i­ties like send­ing texts, con­trol­ling one’s Mac with AppleScripts, etc.

These func­tion­al­i­ties make it in­creas­ingly likely that the model will process both sen­si­tive and un­trusted data sources (which the user does not re­view man­u­ally for in­jec­tions), mak­ing prompt in­jec­tion an ever-grow­ing at­tack sur­face. We urge users to ex­er­cise cau­tion when con­fig­ur­ing Connectors. Though this ar­ti­cle demon­strated an ex­ploit with­out lever­ag­ing Connectors, we be­lieve they rep­re­sent a ma­jor risk sur­face likely to im­pact every­day users.

To use the Mastodon web ap­pli­ca­tion, please en­able JavaScript. Alternatively, try one of the na­tive apps for Mastodon for your plat­form.

The URL short­ener that makes your links look as sus­pi­cious as pos­si­ble.

Normal links are too trust­wor­thy. Make them creepy.

Please see the be­low state­ment in re­gards to the le­gal nasty­grams:

This web­site is a joke. Redirect pages are in place to in­form the user of what web­site they are be­ing di­rected to. It is not de­signed to “weaken global cy­ber­se­cu­rity hy­giene” and does not fa­cil­i­tate phish­ing.

This web­site does not vi­o­late any known laws, poli­cies, or rules, to the best of the au­thor’s knowl­edge.

Valid con­cerns brought up in your let­ter have been ad­dressed. Going for­ward, I would greatly ap­pre­ci­ate if you would reach out at [email de­ob­fus­ca­tion failed] to dis­cuss con­cerns or prob­lems with this ser­vice, rather than send­ing le­gal threats.