Dev.to Security ๐Ÿ” Cybersecurity ๐Ÿ‘ 0 ๐Ÿ“– 6 min read

Kule, screen by screen: an AI agent's task from prompt to undo

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

Kule, screen by screen: an AI agent's task from prompt to undo

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.

How I took these screenshots

I'll say this first, so nothing below looks staged:

  • This is Kule's real window (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.
  • The project is a tiny Node CLI I made for this post, tiny-weather: four files and one git commit.
  • The agent is not a model. It's 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".

1. The agent at work, and a question

Kule's window while the agent works: the task under "Needs you", tool calls in the Agent panel, and a card asking whether the agent may connect to api.open-meteo.com:443

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.

2. Review: what changed, and what the policy says

The Review tab: "Denied by the policy" at the top (package.json needs approval, the git hook is denied), then the modified files with the functions, variables, JSON keys and Markdown sections that changed

This is the screen I care about most. At the top is the ruling, and the rule behind each part of it:

  • package.json needs approval (manifests-and-lockfiles). It decides what gets installed and run, so a person looks at it.
  • The new git hook is denied (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.

3. Timeline: every step

The Timeline tab: "Before the first step", then steps 1 to 6, each with the files it changed and the actions "Go back here" and "Fork from here"

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.

4. A terminal in the same sandbox

A terminal tab marked "in the sandbox": ls shows the project, while ls ~/.ssh, ls of the projects folder, cat of another project's .env and curl to example.com are all refused

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.

5. Approve and commit

Review now says "Waits for your approval": only package.json is held, and the button reads "Approve and commit"

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:

A red notice: "a terminal is open on this task's copy (in Kule's app, or kule shell); close it first, then commit"

I still had the terminal open on the copy, so Kule wouldn't commit. Fair enough. I closed the terminal and clicked again.

The Timeline after the commit: "Commit 1" with README.md, package.json, src/cli.js, src/format.js and the new test, plus an Undo button

Commit 1 shows up in the Timeline with what it applied. The real folder now has the changes, and no hook.

6. Undo

The Timeline after undo: "Commit 1 ยท undone" struck through, and a notice "Undid commit 1"

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.

What these screenshots don't show

  • A real model. With Claude Code, Codex or Gemini you'd also see the agent's own messages and thinking, and what the run cost in the task header (the header here says "nothing spent yet").
  • Refusals listed on Linux. Linux doesn't tell Kule what the sandbox refused; the command just gets a permission error, and the run ends with a line that says so. macOS reports them, and Kule lists them in Live and the Timeline.
  • Windows. Windows 11 has had release files for a few previews now, but I've only tested it in an ARM64 virtual machine, not on a real x64 PC yet. It's the least tested of the three.
  • A finished product. It's still a preview, and screens will keep changing.

What changed since my last post

I last wrote about 0.2.0-preview.14; the latest is 0.2.0-preview.20. The biggest changes:

  • A task's commands read only what's granted: the copy, the system, your toolchains, and folders you add with kule tools add. The rest of your home simply isn't there for them. That's what you see in the terminal screenshot.
  • Windows 11 builds, with the limits above.
  • 19 security advisories published so far, each one after its fix had shipped.
  • Mutation testing (cargo-mutants) runs in CI on every change, on macOS and Linux, on top of the tests that run on real processes and the real filesystem.

Try it, and tell me what got in your way

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 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. ๐Ÿ™

๐Ÿ“ฐ Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.