kato ★ GitHub
Autonomous coding agents · one control surface

Run all your coding, tasks, and approvals from a single place.

Kato is the single cockpit for your coding agents: every ticket in one tabbed UI, every approval in one popup so they never stall, and git locked behind your click — a whole fleet working while you stay in control.

Download the app → View on GitHub $ pip install -e .  ·  kato up
80%more tickets shipped

Used daily by every developer at Una. Una's lead developer ships 80% more tickets with Kato than with AI coding tools alone, measured from the team's git history.

Download

Get the desktop app.

Native app for your OS — bundles the runtime, shares your ~/.kato state with the CLI, and auto-updates as new versions ship.

Your OS macOS .dmg · Apple Silicon Download → Your OS Windows .exe installer Download → Your OS Linux .AppImage Download →

Latest release · All versions & release notes →
Requires git and an agent CLI (Claude Code or Codex) on your machine. Docker only for the optional sandbox.
The Windows installer isn't code-signed yet: if Windows says "Windows protected your PC", click More info → Run anyway.

Why teams run Kato

Four things you get the moment you point an agent at real work.

Coding agents are powerful but sprawling — they run shell commands, touch credentials, and scatter across terminals. Kato turns that into one governed cockpit.

01

One place to work every task

Every ticket the agent is on — across every repo and tracker (YouTrack, Jira, GitHub, GitLab, Bitbucket, Azure DevOps) — in one tabbed cockpit. No more hopping between terminals, IDEs, and tabs.

02

One approval popup, one record of every decision

Every permission ask, from every task — even backgrounded ones — surfaces in a single popup, so your agents never stall. Every "Allow always" and "Deny always" is kept in one list you can review and revoke at any time.

03

Reviewed until it's clean

An independent, read-only reviewer reads the whole change and posts its findings into the agent's chat. Kato goes round again until nothing blocking is left, and no review starts while the tests fail. The agent answers every finding: fixed with a test, or rejected with evidence.

04

Security you can see — and git only through Kato

A 3-layer Action Guard blocks credential reads, network exfiltration, remote-exec and sandbox escapes, and asks before dual-use actions. Agents never touch git directly — every push and PR goes through Kato, on your click.

The loop

Ticket in, reviewed pull request out — with a gate only you can open.

01
Pick up ticketfrom your tracker
02
Clone & branchisolated workspace
03
Write the codeClaude / OpenHands
04
Run your testsin the sandbox
05
You approveDone — Push
06
Open the PR+ summary on the ticket
Governed by default

Trust isn't a setting you hope is on — it's visible, and git is off-limits to the agent.

action guard · block × 4 · ask × 6 · allow × 0
BLOCKCredential reads · .env, SSH keys, keychains, tokens
BLOCKNetwork exfiltration · uploads, reverse shells
BLOCKRemote code execution · curl … | sh · always
BLOCKSandbox escape · always
ASKDestructive file operations · rm -rf, chmod · disk wipes always blocked
ASKWrites outside the task folder
ASKPersistence · ~/.bashrc, crontab, systemd
ASKPrivilege escalation · sudo
ASKWeb access · fetch, search, connectors
ASKNew or unknown tools · each new capability needs your OK

Git flows only through Kato

The agent's direct git access is blocked (Bash(git:*) on every spawn). Branches, pushes, and PRs happen through Kato — nothing reaches your remote without your click.

Nothing ships without you

No auto-commit, no auto-push, no auto-resolve. Kato makes the change, runs the tests, and stops.

Isolated per-task workspaces

Each task runs in its own sandboxed clone. In-review clones are never auto-deleted; Kato never deletes a task or workspace on its own.

Approve the repos it may touch

One screen to approve which repositories Kato can act on — instead of trusting a config file you can't see.

Optional · Docker sandbox · gVisor by Google

Four walls between the agent and your machine.

Turn on the sandbox and every Claude Code run goes into a hardened container on Google's gVisor kernel. It sees only the task's folder, can reach only Anthropic's API, and gives up every privilege once it starts.

One switch in Settings; it needs Docker with gVisor, so it runs on Linux, or on macOS and Windows inside a Linux VM (Docker Desktop can't run gVisor). By default, if a protection can't be put in place, Kato won't start the agent.

How secure is it? To reach your machine, code inside would have to do all four

01Get past the guardKato's Action Guard stops credential reads, exfiltration and escape attempts before a command runs.
02Break Google's gVisorA user-space kernel from Google stands between the agent and your machine's kernel — the isolation Google uses for untrusted code in its own cloud.
03Beat the container's limitsNo root, no Linux capabilities once it has started, a read-only filesystem and AppArmor.
04Find a way outThere is one: Anthropic's API, checked by hostname and pinned certificate. Everything else is dropped.

The highlights

The agent never leaves it

Every chat turn, test run and review runs inside. There is no fallback: if the sandbox can't be set up, the run is refused, never moved to your machine.

Google's gVisor kernel

A user-space kernel between the agent and your machine's kernel, checked again before every run. There is no switch to run without it.

Only the task's folder

Nothing else on your computer is visible. Kato refuses to mount your home folder, system folders, or anything holding keys, passwords or browser data.

One way out

Each task gets its own private network whose only exit leads to Anthropic's API — hostname checked, certificate pinned.

A secret scan before every run

If the task's folder holds credential files — .env, SSH keys, cloud credentials — or anything that looks like a key or token, the agent doesn't start.

Checked, not promised

kato sandbox verify runs 14 checks inside a real sandbox, and Kato's build fails if a required protection ever goes missing.

See all 17 protections
The agent stays inside
  1. Never leaves. Every agent run goes into the sandbox; if any part of it can't be set up, the run is refused.
  2. Google's gVisor kernel, checked again before every run, with no switch to turn it off.
  3. No privileges: a non-root user, every Linux capability gone once it starts, no privilege escalation, and AppArmor.
  4. A read-only system: the root filesystem is read-only, and temporary folders can't run setuid programs or use device files.
  5. Its own namespaces for shared memory and control groups, kept apart from your machine's.
  6. Only the task's folder is mounted. System folders, the Docker socket, your home folder itself, and folders holding keys, keychains, browser data, mail or messages are refused.
One way out
  1. A private network per task, whose only exit is a proxy that checks the hostname and lets through only Anthropic's API.
  2. A default-deny firewall inside the container: IPv6 off, DNS only through fixed resolvers, and your local network, the Docker host and cloud metadata addresses blocked.
  3. A pinned certificate: Anthropic's TLS certificate is pinned, so a rogue or mis-issued one is rejected.
Around every run
  1. A secret scan of file names and contents before the agent starts.
  2. Replies checked for leaked credentials and risky commands like curl … | bash.
  3. A hash-chained audit log of every run, with an optional copy kept off the machine.
  4. Cleanup: a watchdog removes the container if Kato dies, and leftovers are swept at the next start.
  5. Limits on how often runs start, and on memory, CPU, processes, open files and temporary space. No swap, no core dumps.
What it's built from
  1. Pinned builds: the base image is pinned by digest, and Claude Code by exact version.
Proof
  1. Checked by machine: kato sandbox verify runs 14 checks inside a real sandbox, and tests fail the build if a required protection disappears or a forbidden one, like --privileged, appears.
Rules around it
  1. No shortcuts: Kato refuses to run as root, turning off the permission prompts is allowed only inside the sandbox and after a double confirmation at a terminal, and the Action Guard and git-only-through-Kato still apply.

What no sandbox can stop. The agent still talks to its model, so it can send the model what it reads in the task's folder — that is why Kato scans the folder for secrets before every run. Common container escapes are closed by default; attacks on hardware or firmware are beyond any software, so for those, run Kato on a separate machine or VM.

Bruce Lee as Kato in The Green Hornet (1966)
Named for the one who does the work

Put a fleet of agents on real tickets — without losing sleep over what they might do.

Kato — the masked sidekick who did the hard work — now runs your coding agents. One place, one approval popup, git only through you.

Kato will help you kick all your tasks.

Download the app → View on GitHub github.com/shay-te/kato