The pi coding agent needs a runtime. Kortix is the open-source AI Operating System for it

title: The pi coding agent needs a runtime. Kortix is the open-source AI Operating System for it

pi ships without a permission system of its own, so the open-source runtime around it decides what the agent can reach and what survives the session. Feature comparisons rarely mention it. Kortix is the open-source AI Operating System, and it runs pi this way. Each session gets its own sandbox. pi's tool calls are gated from the project's config, and the result goes through a change request that, by default, someone else reviews.

What pi deliberately leaves out

pi is a minimal agent harness, in its own words, and the minimalism reaches further than the command list (pi.dev). Its README states the boundary: "Pi does not include a built-in permission system for restricting filesystem, process, network, or credential access. By default, it runs with the permissions of the user and process that launched it" (pi's README). The model starts with four tools, read, write, edit and bash; grep, find, ls and powershell ship as built-in tools too. Everything else arrives as something you add. pi ships with powerful defaults and skips features like sub-agents and plan mode. Extensions, skills, prompt templates and packages from npm or git bring them back (pi.dev).

For one developer at a terminal, pi is a good coding agent. The same traits make it awkward to hand to a team. pi installs with one command and reads provider keys from the environment across fifteen-plus providers. Models switch mid-session with /model, and every session is a tree you can rewind, export to HTML or upload as a gist.

An API coding agent sits between a model and a machine. It sends prompts and tool calls over an API, runs the tools it is told to run, and repeats until the work is done. pi is one of them. The API half of that definition travels with you, since any provider key moves between machines. The machine half does not travel, and whoever supplies the machine supplies the limits.

pi's own answer to the isolation question

The README does not leave that gap unaddressed. It points at three ways to bound pi, each documented by the people who wrote the harness. The Gondolin extension keeps pi and provider auth on the host while built-in tools route into a local Linux VM. Plain Docker runs the whole pi process in a local sandbox, and OpenShell runs it in a policy-controlled sandbox (pi's README). pi.dev says the same thing in its own list of what it did not build: run pi inside a sandbox, or add a confirmation flow with an extension.

The three do not isolate the same amount. Docker and OpenShell isolate the whole process, so the built-in tools can reach only what you expose to the sandbox. Gondolin isolates only the built-in tools and ! commands. The host pi process stays where it is, and so does any extension that does not use the isolated backend (pi's isolation notes). A host directory mounted into any of the three stays reachable from inside.

The network is a separate setting. pi's security notes put it plainly: credentials and network services stay reachable if you make them available inside. They also tell you to restrict network access where a command does not need it.

What the sandbox does not carry

A sandbox bounds a process. Who the agent was working for is a separate question. Run pi in Docker on a laptop and the credentials inside belong to the person at that laptop. The git remote is the one their ssh config names, and the branch that reaches a server was pushed by hand from that machine. The agent inherits one employee's standing, and the only check on how far that reaches is how carefully the person set the mounts.

The record takes the same shape. Sessions live as trees in one file, an export is an HTML file you ask for, and sharing is a gist upload. Those are good ways for one person to keep their own history. They leave a colleague with whatever that person chose to export. A reviewer at the other end of a push sees the diff without the tool calls behind it.

Where Kortix puts pi

Kortix's harness module states the arrangement in one line: "Since 2026-10-23 every new box runs pi." There is no pi_harness flag, and the manifest's runtime: selects nothing. The module adds that "There is no per-request switching: one box, one harness, for the life of the box" (the harness module in Kortix's source). The release is pinned in the source: PI_HARNESS_VERSION = 'pi-agent-core@1.2.0', whatever a package manager would have resolved that morning.

One isolated sandbox per session. Each session has its own isolated machine and branch, so two agents on the same project never share a working tree.

The permission system pi does not ship is the next thing the runtime supplies: in a v2 project the permission block sits in the agent file's frontmatter, while a v3 project keeps it in the agents.<name> block of kortix.yaml (Read the docs). Each rule resolves to allow, ask or deny, and the docs' own example reads like this:

permission:
  edit: allow
  bash:
    "*": ask
    "git status": allow
    "git diff *": allow
    "git log *": allow
    "rm -rf *": deny
  webfetch: ask

That agent edits files freely and runs read-only git commands without a prompt; any other shell command waits for a person. A recursive delete is refused. The most specific rule wins on pi, whatever order the keys are written in, so "*": ask is the fallback, and a longer pattern overrides it. Because pi brings no rules of its own, this block decides, for every call the model makes, whether the tool runs, waits or is refused.

The committed work travels the same route. A session's branch is named with its session_id, and the agent commits, pushes there and opens a change request. Session work reaches main through a change request, and merge is default-deny for agents: a session merges only when its agent's grants include project.gitops.merge. By default, someone else reads the diff; a session with that grant can merge its own change request. The branch outlives the sandbox that wrote it.

Where it all runs is your call. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

Install it tonight, decide the rest

The pi coding agent is free to run; model calls are the bill, and they go to whichever provider key or subscription you connect. pi.dev publishes one-line installers for macOS, Linux and Windows and lists the project under the MIT license (pi.dev). On a Mac or Linux machine the install is curl -fsSL https://pi.dev/install.sh | sh, and it needs Node.js 22.19 or newer (pi's README).

Ending the pi process stops it, since pi runs in your terminal as your own account. The session tree stays in its file, and /tree takes you back to an earlier point when you start again. That much does not change because the work belongs to a company. What stays open is whose sandbox runs pi, whose permissions it carries, and who reads the branch it leaves.

Two posts carry the rest of that argument. The harness as a component covers where the boundaries live, and Kortix vs OpenHands covers what a change request adds to a coding harness. Free to start and free to self-host: Try Kortix.