AI can make an app. Sharing it is still the hard part.

Yashraj Pardeshi — Thu, 30 Jul 2026 07:54:56 +0000

A while ago, I made a small Mac app called NoTabsConfusion. It highlights the windows I used most recently, and it saves me from opening the wrong window while I work.

It was useful to me. Sharing it was the difficult part.

I could give another developer the source code. I could pay for Apple's developer program and distribute a signed Mac app. But I could not simply send the tool to someone using Windows or Linux. Even on a Mac, the person receiving it would have to trust an app they did not write.

AI makes this problem much bigger.

People can now ask Claude for a grocery list, a habit tracker, or a tiny tool made for one specific job. Creating it may take minutes. Giving that app to another person is still a software distribution project.

I am building Krate to test a simpler model: small apps should be shareable like documents.

With Krate, Claude can create an app from one request:

krate create "Make a grocery list app with milk, eggs, and bread" \
  --agent claude \
  --output groceries.krate

The result is one .krate file.

That same file opens locally on Mac, Windows, and Linux. Before any code runs, Krate shows what the app wants to access, such as a window, a folder, or the network. The user chooses, and the runtime gives the app only what was approved.

What works today:

Claude can create a Krate app from a plain request
the result is one shareable file
the same file opens on all three desktop operating systems
permission choices are enforced by the runtime
local app data survives closing and reopening
the runtime, format, authoring tools, and MCP interface are open source

Krate Cloud is the next product, not something I am claiming is already built.
It will let people publish, find, share, and update these small apps while the
apps continue to run locally under the same permission controls.

Right now I care about the first user journey. I want to know whether someone who did not build Krate can make a small app, open it, understand the permission screen, and send the file to somebody else.

If you use Claude Code, try making one small app and tell me the first point where the process becomes unclear or fails.

Make an app:
https://incyashraj.github.io/krate/docs/pages/make-an-app-with-ai.html

Demo:
https://youtu.be/i1ksbR-kPgc

GitHub:
https://github.com/incyashraj/krate

Every AI sandbox in 2026 runs in someone else's cloud

Yashraj Pardeshi — Wed, 22 Jul 2026 05:45:30 +0000

Modal published a comparison of the best code execution sandboxes for AI agents. Seven providers: Modal, E2B, Northflank, Daytona, Blaxel, Vercel Sandbox, Cloudflare Sandboxes.

Every single one is cloud-hosted. Every single one isolates with containers or microVMs. Not one of them uses a capability-based permission model, and not one runs on the machine the developer is already sitting at.

That is not a criticism of those products. They are good at what they do, and for most agent workloads the cloud is the right answer. But it means an entire half of the problem has no serious entrant, and I think that half matters more than it looks.

The assumption nobody states

Every one of those tools starts from the same premise: untrusted code should run far away from the user, in an environment that can be destroyed.

That premise is correct for scale. It is wrong for a large and growing class of work, because the interesting things an agent does are usually about your stuff. Your files. Your local database. Your credentials. The application you are building right now. Ship that work to a remote microVM and you have to ship your context with it, which is either a security problem or a synchronization problem, and usually both.

So you end up with two bad options. Run agent-written code in the cloud and lose access to the local context that made it useful. Or run it locally with ambient authority, which means a script that was supposed to rename some files can read your SSH keys, because on every mainstream operating system a process inherits everything you can do.

Isolation solved the first problem. Nobody solved the second one, because the second one is not an isolation problem. It is a permission problem.

Container isolation and capability permission are different things

A container answers: what machine is this code on?

A capability answers: what is this specific code allowed to touch, right now, and who decided that?

You can have excellent isolation and terrible permissions. A microVM with a container full of your credentials is a strong wall around a room where everything is unlocked. The wall stops the code escaping to the host. It does nothing about what the code does with what is already inside.

The capability model inverts the default. Code starts with nothing. Not a restricted filesystem, not a read-only mount. Nothing. Then a specific grant is made for a specific resource, deliberately, by a human or a policy:

$ krate run --grant fs.read:./secrets.txt --manifest app.toml cat.wasm -- ./secrets.txt

Without that grant the same binary running the same code cannot open the file. It does not crash on a permission error deep in a syscall. It gets a structured denial: this capability was requested, it was not granted, here is the identity of the thing that was denied.

That last part is the piece I think is underrated for agents. A generic EACCES tells an agent that something went wrong. A structured denial tells it exactly which authority it lacks, which means it can ask for that specific thing, or route around it, or report to the user precisely what it needs and why. Failure becomes information instead of a dead end.

What I built

Krate is a runtime for that model. A program is one WebAssembly component in a single file. It runs natively on macOS, Windows and Linux, opening a real desktop window, not a bundled browser. It starts with zero ambient permissions and receives capabilities only through explicit grants.

The demo application is 24 kilobytes. The same file, unmodified, runs on all three operating systems.

Here it is running, end to end, in four minutes:

I want to be precise about what is and is not proven, because this space is full of claims.

Every push to the repository triggers CI across all three operating systems. On all three, the component is built and executed and opens a real window. On Linux, CI goes further: it runs the app under Xvfb, uses xdotool to click the button, type into the text field and scroll the list, then photographs the screen and uploads the image as a build artifact.

This screenshot was taken by a machine I have never touched, before I wrote this sentence:

The click-and-photograph step is Linux only today. macOS and Windows run the component and open real windows in the same CI run, but are not yet driven synthetically. Extending that is on the list.

The other honest caveat: on macOS, widgets are real AppKit controls, genuine NSButton and NSTextField. On Linux and Windows the widgets are currently drawn through a shared rendering path rather than being native OS controls. The window is real on all three. The controls inside it are not equally native yet.

Why this shape, and why now

Two things had to become true for this to be buildable at all.

The WebAssembly Component Model matured to the point where one compiled artifact can carry typed interfaces across languages and hosts. That is what makes a single file legitimately portable rather than portable-if-you-squint.

And AI started generating far more software than humans can review. That changes the economics of trust. When a person writes code and runs it, they have some idea what it does. When an agent writes it, nobody has read it, and the honest position is that you do not know. Ambient authority was always a bad default. It becomes an untenable one at machine-generated volume.

Neither curve produces this on its own. The intersection does.

What I am not claiming

Krate is not a replacement for cloud sandboxes. If you are running ten thousand concurrent agent tasks, you want microVMs and a control plane, and you should use one of the seven products above.

It is also early. There is no SDK yet, the developer experience is rough, and the honest state of it is in STATUS.md rather than in a marketing page.

What I am claiming is narrower: local execution with a real permission boundary is a missing primitive, the entire market has been building the other half, and a portable component format with capabilities attached is a plausible shape for the missing piece.

If you build agents

The question I actually want answered: if you were routing agent-generated code through something like this, what capability would you need first that does not exist yet?

That answer is worth more to me than a star. The repo is public, the CI evidence is in the Actions log, and my DMs are open.

Repo: github.com/incyashraj/krate
Original post on my site: incyashraj.github.io/krate

DEV Community: Yashraj Pardeshi