I built Kule: AI agents work on a copy of your folder, and you decide what comes back

Hi, I'm Selçuk. I've been building an open-source tool called Kule, and its first preview release is out. I'd like to tell you what it does, why I built it, and what it can't do yet.

The short version: Kule is a control room for AI agents that work on your folders. You point an agent (Claude Code, Codex, Gemini, or any agent that speaks ACP) at a folder. Kule gives it a copy-on-write copy of that folder inside a sandbox, looks at what every command really changed, and lets nothing reach the real folder until a policy, or you, says so. Every commit can be undone.

("Kule" means tower in Turkish. Think control tower.)

The problem I kept running into

Coding agents are good now, good enough that we let them run commands. When an agent runs a command, it runs as you: your files, your ~/.ssh and ~/.aws, your ~/.zshrc, your network, your API keys.

Most agents ask before they run something, but they ask about the command text: "Run npm install?" You can't tell from that text what a postinstall script, a Python one-liner or a build script will actually touch. So after the twentieth prompt you start clicking "yes" without reading, or you switch on the mode that stops asking. And if a file the agent reads contains a prompt injection, the agent is on the attacker's side, and all that's left is what you approve.

I wanted something else: let the agent work freely, somewhere nothing it does is real until I've seen it.

The loop

Kule has one loop, in the CLI and in the desktop app:

make a task → give the agent a prompt → watch → review → commit or roll back.

Here it is without an agent, on a scratch folder:

mkdir -p ~/kule-demo && echo "hello" > ~/kule-demo/notes.md

kule new ~/kule-demo                                    # prints a task id, e.g. 1a2b3c4d
kule exec 1a2b3c4d -- sh -c 'echo "more" >> notes.md'  # runs in the copy, in the sandbox
kule status 1a2b3c4d                                    # what changed, and the policy's verdict
kule commit 1a2b3c4d                                    # apply it, keeping a checkpoint
kule undo 1a2b3c4d                                      # put the folder back

And with an agent:

kule run 1a2b3c4d --agent claude-code "Turn notes.md into a checklist"
kule steps 1a2b3c4d     # every tool call the agent made, and what it changed
kule commit 1a2b3c4d    # or: kule rollback 1a2b3c4d

The desktop app (Tauri) does the same thing with a live stream, an approval inbox, a review screen and a timeline. A small daemon keeps runs going when the window is closed.

What's actually between the agent and your stuff

Your folder. The agent works in a copy-on-write copy: an APFS clone on macOS, a reflink on Btrfs/XFS. Its changes reach the real folder only through a commit, and every commit keeps a checkpoint, so kule undo really puts things back. The history of commits and undos is signed and hash-chained.

Your computer. Every command runs in the OS sandbox: Seatbelt on macOS, Landlock + seccomp + namespaces on Linux. It can write only to the copy and its own temp folders. ~/.ssh, ~/.aws, your Documents and the projects next to the folder are hidden. If the sandbox can't be set up, the command doesn't run. Kule never quietly falls back to "no sandbox".

What gets in. This is the part I care about most. Kule doesn't judge the command; it judges the effects. After a run, it compares the copy with your folder: files created, modified, deleted or moved, git branches moved, hooks added. Then a Cedar policy gives each effect a verdict: pass, ask or deny.

With the default ("balanced") policy:

• ordinary edits to source, notes, documents and data pass;
• manifests and lockfiles, CI files, editor settings, agent instructions (CLAUDE.md, AGENTS.md, .mcp.json…), git config changes, history rewrites and mass deletes wait for you;
• git hooks are denied, because they would run on your next git command, as you.

So a harmless-looking command that rewrites package.json still waits for you, and a scary-looking rm -rf that only touches the copy changes nothing real. When something waits, Kule tells you which rule stopped it:

policy: waits for approval
  package.json · waits for approval (manifests-and-lockfiles)

There's also a "careful" policy where every change waits. You can write your own, and a repository can add refusals of its own, but never loosen yours.

Your network. Every connection goes through the task's proxy. Package registries pass, the agent reaches its own model API while it runs, and anything else waits for your answer. Every connection is logged.

Your secrets. The agent sees a placeholder, never the key. The proxy puts the real value into requests going to the hosts you named, and nowhere else.

Your home. A write to ~/.zshrc, ~/.gitconfig or ~/.config lands in the task's home layer with a diff for you to review. It doesn't touch your real home.

Your wallet and your machine. Cost budgets per task, per group and per day (with a notice at 80%), CPU/memory/disk/time limits per run, and a Stop button.

Not only for code

Kule works on any folder. The review shows what changed inside a file (functions and methods, Markdown sections, JSON/YAML keys), before-and-after pictures, and previews for CSV, Excel and Word. If you let an agent tidy your notes, rename photos or clean up a data folder, the same loop applies.

Two tasks can work on the same folder. A file both of them changed merges method by method, and only the parts that were changed twice conflict.

The honest part: what it can't do (yet)

I'd rather you hear this from me than find out after an hour of setup:

• It's a preview (0.2.0-preview.1). Things will change between previews.
• macOS 13+ and Linux x86_64 only. Windows is planned, not started.
• The macOS app isn't notarized. It's signed ad hoc, so Gatekeeper will complain the first time. Every release file comes with SHA256SUMS, a build provenance attestation and an SBOM, and the install guide shows how to check them and open the app.
• Linux has some requirements. On ext4 the copy is a full copy, not a clone. The sandbox needs Landlock (Linux 6.2+, 6.7+ for network rules) and unprivileged user namespaces, which Ubuntu 24.04 restricts by default. Kule tells you what's missing and won't run an agent with weaker isolation unless you choose that knowingly.
• The proxy doesn't do HTTP/2 or WebSockets yet. Clients fall back to HTTP/1.1. A few tools on macOS have certificate quirks; the Platforms page lists them all.
• Kule doesn't make the agent right. It makes the agent's mistakes cheap and visible. You still review, and Kule's job is to make that review short and honest.
• It's built by one person. I take security seriously (every boundary has a test that fails without it, on real processes and the real filesystem, no mocks), but one person can still miss things. That's part of why it's open.

Try it

• Download: releases page (universal .dmg, .deb, .rpm, and the CLI alone as .tar.gz)
• Or build from source:

  git clone https://github.com/kulehq/kule && cd kule
  cargo build --release -p kule -p kule-desktop

• Docs (English and Turkish), with a quick start, a page for every command and a three-minute video tour: kulehq.github.io/kule
• Code: github.com/kulehq/kule · Apache-2.0 · written in Rust

What would help me most

Try it on a real folder and tell me where it got in your way. A policy that asks too often, a confusing screen, a tool that breaks inside the sandbox: that's exactly the feedback I'm looking for. Open an issue, or just reply here.

If you find a way through one of the boundaries, please don't post it publicly. Report it privately as SECURITY.md explains. I'll be grateful, and I'll fix it.

And if Kule ends up keeping your folders safe and you'd like to help it keep going, there's GitHub Sponsors. That's completely optional. A star, an issue or a "this worked for me" means a lot too.

Thanks for reading. 🙏