Hi again. My first post about Kule was all CLI commands, and I kept wanting to show you the window instead. So this one is screenshots: one small task, from the prompt to the undo, with nothing cut out. That includes the two places where Kule stopped me.
Kule in one line: AI agents work on a copy of your folder, inside a sandbox, and nothing reaches the real folder until you review it and commit it.
I'll say this first, so nothing below looks staged:
0.2.0-preview.20) on Linux, running in a throwaway container on a virtual display. On macOS the window has its native title bar; the rest looks the same.tiny-weather: four files and one git commit. kule-test-agent, the scripted agent Kule's own tests use. It speaks the same protocol (ACP) as Claude Code or Codex, but it runs a list of steps I wrote. That way one run could show a question, an approval and a refusal, and I didn't have to put a real agent's login into a throwaway container. Everything around the agent is real: the copy, the sandbox, the proxy, the policy, the review, the commit and the undo.
The script asked the "agent" to add a --units option, write a test and a README section, bump the version and require Node 20 in package.json, add a git pre-commit hook that runs the tests, and then check that the forecast API answers. That's roughly what an eager agent might do if you asked it to "add Fahrenheit support and make sure the tests run before every commit".
Your tasks are on the left. While the agent works, the bottom panel (Live) shows each tool call on one line, the files it changed after the arrow, and its output under it. The bar at the bottom shows what the run is using: CPU, memory, disk and processes.
Then the agent tried to reach api.open-meteo.com. Package registries and the agent's own model API go through on their own; any other host waits for a person. So the connection is held, a card shows up, and the task moves under Needs you. The card tells you what approving means (a tunnel: Kule sees the host and port, not what's sent over it), which rule held it, and what happens if nobody answers: after 15 minutes the connection is refused and the agent carries on without it.
I pressed Deny. The agent's curl got a 403 from the proxy, and the run finished.
This is the screen I care about most. At the top is the ruling, and the rule behind each part of it:
package.json manifests-and-lockfiles). It decides what gets installed and run, so a person looks at it.git-hooks). A hook runs on your next git commit, as you, so an agent doesn't get to add one.
Below the ruling, each file shows what changed inside it, by name: function format, variable SIGN, key engines, section Units. You can read what happened before you open a single file. Click a file to see it in Preview, as it is in the copy.
Something I want to be upfront about, because my own docs get it slightly wrong: while a denied change is in the pile, nothing gets committed. The window offers only Roll back, and kule commit --approve refuses too. Parts of the docs say denied changes are "held back" on a commit, which suggests the rest would go through. What Kule actually does is the stricter thing, but the docs, and a hint the CLI prints, should say so. That fix goes into the next preview.
Every tool call that changed something is a step. Go back here puts the copy back the way it was after that step. Fork from here starts a new task from that point, so you can try another direction without losing this one.
Going back to a step doesn't touch .git, though, so for the hook I used a terminal.
The bottom panel also has terminals, and they run in the task's sandbox, just like the agent. Here ls shows the copy. The home folder's ~/.ssh (I put a dummy key there), the folder with other projects, and another project's .env are all refused. curl to a host the policy doesn't let through gets the same 403. git status shows the agent's changes, because the copy is a full working copy, .git included.
From here I removed the hook with rm .git/hooks/pre-commit. That's a change in the copy too, so Review judged it again.
With the hook gone, the ruling is Waits for your approval and the button says Approve and commit. If you tick Don't ask again in this folder, Kule first shows what that would have let through, then remembers it for this folder.
My first click didn't work:
I still had the terminal open on the copy, so Kule wouldn't commit. Fair enough. I closed the terminal and clicked again.
Commit 1 shows up in the Timeline with what it applied. The real folder now has the changes, and no hook.
Undo takes two clicks: the first one turns red and asks again. It puts back what the commit replaced, from the checkpoint Kule kept. Afterwards I checked the real folder: git status was clean and package.json was back at 0.1.0.
I last wrote about 0.2.0-preview.14; the latest is 0.2.0-preview.20. The biggest changes:
kule tools add. The rest of your home simply isn't there for them. That's what you see in the terminal screenshot.
If a screen confused you, or a card asked too often, tell me here or in an issue. If you find a way past one of the boundaries, please report it privately as [SECURITY.md](https://github.com/kulehq/kule/blob/main/SECURITY.md) explains, not in public.
If this kind of walk-through is useful, I'd like the next one to be about the policy: how Kule decides what passes, what waits and what's denied, and how to write your own rules. Tell me which screen you'd like to see up close.
Thanks for reading. 🙏