kortix-ai/suna: one kortix.yaml, a sandbox per session, a change request to main

Every session gets its own sandbox on a branch named after it

The unit of configuration here is a git repository, not a settings screen. `kortix init` scaffolds a project and creates `kortix.yaml` alongside your agents, skills and runtime config, and the intent is that the whole company is something you clone and diff. The runtime shape is this:

project  (git repo + kortix.yaml)
   └─ session ──> cloud computer: an isolated sandbox on a branch named after the session
                     └─ the OpenCode agent works
                           └─ change request ──> you review & merge ──> main

Each session gets a disposable, isolated Linux sandbox, and the branch inside it carries the session's name. The sandbox is deliberately unguarded: the agent can install, run and break anything inside it, and only what it commits survives. Work reaches main through a change request that a human reviews and merges, which is the mechanism that stops agents that are able to rewrite themselves from quietly rewriting the company while nobody watches. The same config can run thousands of these sandboxes in parallel, each isolated, each returning work as change requests rather than as side effects.

kortix init, kortix ship, and the curl that installs the CLI

Onboarding is three commands, and the first one pipes a script straight into your shell:

curl -fsSL https://kortix.com/install | bash
kortix init
kortix ship

The first line downloads the CLI installer from kortix.com and hands it to bash, with no version flag and no checksum in the command itself. The second scaffolds the project locally, which is where kortix.yaml, the agents, the skills and the runtime config come from. The third pushes your repo and brings the whole thing live in the cloud. After that the working surface is three more commands:

kortix sessions new --prompt "Summarize this week's commits and open a change request"
kortix cr ls
kortix chat

`sessions new --prompt` starts a session with a written instruction, `cr ls` lists what agents are proposing so you can merge what you want to keep, and `chat` talks to a session's agent from the terminal. Notice where step three points by default: shipping means their cloud unless you switch hosts first.

Self-hosting still pulls its images from Docker Hub

The other destination is your own hardware: a laptop, a VPS, your VPC or an on-prem network, started from Docker images.

kortix self-host start
kortix hosts use selfhost

The second command is the switch, and the same command with `cloud` sends the CLI back to the managed service. The interactive setup asks only for the integration credentials that unlock managed git, GitHub access and Pipedream connectors, and generates ports, local URLs, keys and Docker Compose defaults for you. The catch sits in the next sentence: `self-host start` pulls its images from Docker Hub, so this is a self-hosted install and not a disconnected one. That distinction decides whether the path works for you. On a network with no route to a public registry, or under a policy that forbids images fetched from outside, the install stops at the pull, and no offline or air-gapped procedure is described to fall back on. Self-hosting here means you own the machines, not that you own the supply chain.

Connector keys stay outside the sandbox, agent secrets go in

Kortix handles credentials two different ways, and the difference sets your threat model. Connectors cover 3,000+ apps plus MCP, OpenAPI, GraphQL and raw HTTP, and their credentials are brokered server-side through one scoped token that never enters the machine, so an agent can use a connector without holding the raw key. Secrets work the other way round. They are encrypted at rest, granted per agent, and injected into the sandbox at runtime, where a granted secret is a real environment value for that session. The README says that in plain words instead of hedging it. Once a secret is granted, the agent in that sandbox can read it and print it, so the protection is the grant, not the encryption at rest. Version v0.13.47 extended the same model by adding secrets you can share with an agent.

Slack today, Teams behind a switch, email and voice experimental

Whether your team ever opens the CLI depends on the channels and the triggers. Slack is the settled one: install the Slack app, invite the bot to a channel, and an @-mention starts a session where the work already happens. Microsoft Teams sits behind an operator switch, and email and voice are marked experimental, so plan to switch those on and debug them yourself. Triggers are cron schedules and signed webhooks that spawn sessions with no human present. Put next to on-demand chat and a human-assisted mode where the agent checks in for the calls that matter, that is three ways work runs. The rest of what you manage is quieter: skills written once and shared into every session, and memory that is plain files today, described as a system meant to compound what it learns.

kortix-sandbox:dev is the image your agent runs inside

The repository is a TypeScript monorepo built on pnpm, with pnpm-workspace.yaml, pnpm-lock.yaml, a patches/ directory and a private package named kortix. Its scripts target named workspaces including kortix-api, Kortix-Computer-Frontend, ./apps/mobile, @kortix/desktop-electron, @kortix/cli and @kortix/tui. That layout is also the answer to what an agent can break, because the sandbox is an image you can read and rebuild yourself:

docker build -f apps/sandbox/Dockerfile -t kortix/kortix-sandbox:dev .

That is the dev:sandbox script verbatim. Security tooling is committed rather than bolted on afterwards, with .gitleaks.toml, .gitleaksignore, .semgrepignore, .trivyignore, .deepsec/ and .strix/ at the root, plus a secrets:check script that runs bash scripts/check-env-encrypted.sh. Tearing a local environment down has its own pair of scripts, nuke and nuke:start, which run scripts/nuke-local.sh with and without the --start flag.

Configuration as files in your repo, not settings in their product

The README sets Kortix against Claude Cowork and ChatGPT Work, and the rows that carry weight are structural rather than feature lists. Source: both rivals are closed, Kortix is open source and auditable. Models: Anthropic only and GPT-5.6 only, against any provider with your own API keys. Where it runs: Anthropic's cloud, Bedrock, Google Cloud or Microsoft Foundry with no self-host, and OpenAI's cloud with no self-host, against Kortix Cloud, your VPC or your own on-prem network. Configuration: inside their product, against files in a git repo you own. Access: paid plans on both sides, against self-host free and a managed cloud at $40/seat/mo plus usage. The table dates itself, noting that the competitor rows reflect publicly documented behavior as of July 2026, so treat the rival columns as a snapshot rather than a live audit.

Two releases on 2026-10-01, still numbered 0.13

The project moves fast, which is both the pitch and the warning. v0.13.47 landed on 2026-10-01 with Microsoft Teams for every project, secrets you can share with an agent, failed-trigger alerts and immediate sign-out. v0.13.46 landed the same morning with an agent permission fix, refresh-token replay protection, prompt authorship, and agents that can ask people behind a flag. The last push to the default branch main was on 2026-10-01 as well. Two of those six items are security fixes, which is what you would expect from a system where agents hold granted secrets and long-lived sessions, and it argues for pinning a numbered release rather than tracking main. The release list also carries a floating dev-latest tag dated 2026-05-31, so a branch name is not a version. One more thing to check by hand: the licence metadata for the repository reads NOASSERTION while a LICENSE file sits at the root.

Editorial conclusion

Choose kortix-ai/suna if your team wants agent work to arrive as reviewable change requests in a repository it owns, and if you can live with a CLI, a container sandbox and a pre-1.0 release cadence. Leave it if you need the client side documented, a stable version contract, or an install that never reaches Docker Hub. Verify three things before the first session: read LICENSE, since the licence metadata reads NOASSERTION; read apps/sandbox/Dockerfile, since that image is what your agent runs inside; and pin a numbered release rather than the dev-latest tag.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes