Agents work on branches and return change requests
Kortix gives every agent session an isolated Linux sandbox on its own git branch. The agent can install software, edit files, and run commands there. Work reaches the project's main branch through a change request that a person reviews and merges. This control is useful when the output is code, documents, configuration, or deployed changes.
The project repository stores agents, skills, company memory, connectors, and runtime configuration. Schedules and signed webhooks can start sessions automatically, while Slack can bring sessions into a team channel. MCP, OpenAPI, GraphQL, raw HTTP, and a claimed 3,000-plus app catalog cover external actions.
The design suits companies that want autonomous work to leave an audit trail. It also creates a serious system to operate: sandboxes, branches, model routing, connector brokers, approval settings, and secret delivery must agree about who may do what.
The security boundary ends inside each granted sandbox
Kortix says connector credentials are brokered server-side through a scoped token, so raw connector keys do not enter the cloud computer. Secrets work differently. The README states that a secret granted to an agent is injected as a real environment value inside that session. Code running there can read the value.
Isolation depends on the provider. The README says Platinum uses microVMs while the default uses containers. That difference belongs in a threat model when agents install packages or process untrusted repositories. A merge gate protects the main branch, but it cannot undo an external action or secret disclosure during a session.
Change requests make persistent edits visible and reversible. Pair them with narrow credentials, short-lived tokens, network rules, and approval requirements. Git review is not an authorization system for Slack, email, billing, or production APIs.
What happened when we ran it
Our sandbox installed 2,651 packages in 79 seconds and used 3,393 MB on disk. Commit 2bc6342 contained 8,010 files, about 1,323,679 source lines, and a 243.9 MB checkout. This was a pnpm install in an unprivileged Node 22 container with 3 CPUs, 8 GB of memory, and no secrets.
The build failed with exit code 1 after 4 seconds. Its log shows 20 of 21 workspace projects entering the build, then agent-tunnel and kortix-sandbox-agent-server trying to execute bun. Both reported bun: not found, and pnpm stopped on the first recursive failure. The log does not tell us whether later stages would pass after Bun is installed.
Tests also failed after 4 seconds because the root command is bun tests/bin/local.ts; the shell again reported that Bun was absent. No test cases ran in the supplied log. The repository did contain a tests directory and 31 CI workflow files, while the scanner found no Dockerfile.
The three-command quick start chooses managed cloud
The README opens with kortix init and kortix ship. That path scaffolds a project and pushes it live through Kortix's service. Managed cloud is priced in the README at $40 per seat per month plus usage, a project claim that buyers should recheck before purchase.
Self-hosting starts through kortix self-host start, which pulls images from Docker Hub. Setup asks for credentials that enable managed git, GitHub, and Pipedream connectors, then generates ports, local URLs, keys, and Compose defaults. This is self-hosted rather than disconnected. Air-gapped buyers would need to mirror and inspect the required artifacts.
The contribution section lists pnpm commands for web, API, sandbox, and full builds, but our 3,393 MB install still lacked the Bun executable those scripts called. Add Bun before judging a source change.
Elastic License 2.0 limits what a fork may become
GitHub could not reduce the license to a standard SPDX identifier, so reading the file matters. Elastic License 2.0 permits use, modification, and distribution, but prohibits offering the software as a hosted or managed service that exposes a substantial set of its features. It also protects license-key functionality.
That can work for an internal deployment. It is a poor fit for a vendor intending to rebrand Kortix as its own agent cloud. Source availability does not grant the same commercial rights as Apache 2.0 or MIT. Ask counsel about the intended deployment rather than inferring rights from the marketing label.
Release activity is intense and the stable surface is still forming
The repository was pushed on August 25, 2026, and v0.13.5 was released one day earlier. GitHub listed 44 open issues and pull requests combined; the open search results we checked were pull requests, with current work on gateway compatibility, sandbox startup, session errors, and agent tunnels.
The v0.13.5 notes describe faster sessions, recovery after runtime loss, safer preview origins, bounded database connections, and tighter secret boundaries. They also retire an experimental voice runtime and summarize fixes across session state, billing, webhooks, and deployment. Expect upgrades to touch several services because the web app, API, CLI, desktop client, and sandbox ship under one version.
Kortix has a sharp governance idea: agents work on disposable branches and people decide what persists. Buy into it only if that workflow solves a real organizational problem. A team seeking one coding assistant will move faster with OpenHands, while a team building custom agent logic may prefer AutoGen and a smaller operational surface.