# Why jackin❯? (https://jackin.tailrocks.com/getting-started/why/)
## The problem [#the-problem]
AI coding agents are transforming software development. Tools like [Claude Code](https://docs.anthropic.com/en/docs/claude-code), [Codex](https://github.com/openai/codex), [Amp Code](https://ampcode.com), Kimi, and [OpenCode](https://github.com/anomalyco/opencode) can read your codebase, write code, run tests, install dependencies, and execute arbitrary shell commands — all autonomously.
But there's a catch: **every modern agent runtime is most productive when it runs without guardrails.**
* **`Claude Code`** has a mode called `--dangerously-skip-permissions` that removes every confirmation prompt. No "are you sure?" dialogs. No permission gates. The agent just *does things*.
* **`Codex`** ships a sandbox plus an approval policy that, in their default `workspace-write` + `on-request` configuration, contain dangerous commands behind a prompt. The same CLI also exposes `--dangerously-bypass-approvals-and-sandbox` (aliased `--yolo`), which turns *both* off — Codex's direct equivalent of `Claude Code`'s `--dangerously-skip-permissions`. Operators reach for YOLO for the same reason they reach for `--dangerously-skip-permissions`: permission and sandbox prompts kill agent throughput.
* **`Amp`**, and every other emerging agent runtime, carries its own equivalent of full-speed mode. Permission prompts in front of every shell command kill agent throughput, so every runtime eventually grows a flag that turns them off.
That speed is exactly what you want when an agent is actually getting work done — nobody wants to click "Allow" every ten seconds. And the more capable the model, the more painful permission prompts become *and* the larger the blast radius if something goes wrong. AI models are only going to get more powerful. **Running any of them at full speed against your host machine will always be a substantial risk.**
**What "doing things" actually means on your host:**
* The agent can read **every file** on your filesystem — your SSH keys, your `.env` files, your browser cookies
* It can run **any command** — `rm -rf /`, `curl` data to external servers, modify system configs
* It can install **any package** — potentially pulling in malicious dependencies
* It has your **credentials** — `Docker Hub` tokens, AWS keys, `GitHub` tokens, anything in your shell environment
Running an unrestricted AI agent directly on your host is like inviting a brilliant but unpredictable contractor into your home and saying "do whatever you want." They might build something amazing — or they might accidentally (or intentionally) cause damage you never anticipated.
## The solution [#the-solution]
**jackin❯ gives each agent its own isolated world to operate in.**
Instead of running on your host, each agent runs inside a `Docker` container with `Docker-in-Docker` (`DinD`) enabled. From the agent's perspective, it has full autonomy — it can execute commands, install packages, build `Docker` images, run tests. But from *your* perspective as the operator, you've defined exactly what the agent can see and touch.
1. **You define the boundaries**
Which directories to mount, whether they're read-only or read-write, what tools are available in the container image
2. **The agent runs freely inside those boundaries**
No permission prompts. No "are you sure?" interruptions. The runtime's full-speed mode (`Claude Code`'s `--dangerously-skip-permissions`, `Codex`'s YOLO, whatever the runtime calls it) is exactly what you want — *because the boundary is somewhere else.*
3. **Your host system stays untouched**
The agent can't see your home directory, can't access your credentials, can't modify files outside its mounts
Think of it this way: you're not restricting the agent's *capabilities*. You're restricting its *blast radius*.
jackin❯ also helps you restrict the agent's *context*. You are not forced to put every language toolchain, helper script, and runtime plugin into one universal environment. You can build smaller roles for specific kinds of work and point them at the same workspace when needed.
## jackin❯ is an ecosystem, not an agent [#jackin-is-an-ecosystem-not-an-agent]
There are already excellent products focused on the **agent itself** — better runtimes, better prompts, better tool integrations, more capable models. **jackin❯ is not one of them.**
jackin❯ is the layer **around** those agents. It lets you run *many* of them in parallel, each with its own isolation boundary, its own file access rules, its own tool profile, and its own credentials — without designing those rules from scratch every time. One agent for frontend work, another for backend, another for security review, all on the same laptop, all isolated from each other and from your host.
That ecosystem framing is why every UX choice in jackin❯ — the CLI, the operator console, workspaces, roles, mounts, env scopes, auth forwarding — exists to make isolation *easy and convenient*. The harder isolation is to set up, the more often someone skips it. The faster jackin❯ makes it, the more often it actually gets used.
The agent runtime stays the agent runtime. jackin❯ is the part that decides where each agent lives, what each one can touch, and how many of them you can have running at once.
## What jackin❯ optimizes for [#what-jackin-optimizes-for]
jackin❯ is opinionated about what matters most in day-to-day agent work:
* **local development first** — your laptop is the first control plane
* **open source over black box** — the tool itself should be inspectable and patchable
* **environment as code** — roles should live in normal git repos with normal code review
* **workspace boundaries as first-class objects** — file access should be an explicit operator decision
* **many parallel agents** — different projects, branches, or roles should coexist cleanly
That means jackin❯ is not trying to win every dimension. It is not trying to be the hardest isolation boundary you can put on a laptop. It is trying to make isolated local agent development feel deliberate, reusable, and pleasant.
## Why separate roles from workspaces? [#why-separate-roles-from-workspaces]
This is the part new users usually need spelled out.
A **workspace** controls file visibility. It says which project paths are mounted into the container.
An **role** controls environment and behavior. It says which tools, shells, plugins, and defaults exist in that container image.
Those are different concerns, and separating them is useful for two reasons.
First, it keeps the blast radius clear. The workspace decides which files the agent can reach.
Second, it keeps the agent's working environment focused. The role decides which tools, conventions, helper scripts, and plugins are even present. That matters because a giant all-in-one image creates noise. The model can inspect too many tools, too many conventions, and too much irrelevant context before it decides what to do.
Imagine one company with a shared monorepo:
* the frontend team uses a `chainargos/frontend-engineer` role with Node, Playwright, design-system utilities, and UI-oriented agent plugins
* the backend team uses a `chainargos/backend-engineer` role with Rust or Go toolchains, database clients, and API-oriented plugins
* both teams can still point those roles at the same monorepo workspace when needed
That split keeps the visible project files and the installed toolchain independently controllable.
In practice, this often produces better results than one kitchen-sink agent image. A narrower environment gives the agent fewer irrelevant cues and makes it more likely that the tools and plugins it discovers actually match the task.
It also helps with runtime-specific plugins. A `Claude Code` tool like Superpowers (or any other agent's equivalent extension) can be extremely useful, but it brings hooks and behavior that you may not want in every task. The most reliable way to keep it out of scope is not to "mostly disable" it, but to use a different role where it simply is not installed.
## The cyberpunk analogy [#the-cyberpunk-analogy]
The name "jackin❯" borrows the cyberpunk verb *jacking in* — a cultural idiom for connecting into a simulated environment. The imagery is the classic cyberpunk one: an operator loads a person into a constructed environment where they can train, build, and operate with capabilities they wouldn't have outside it. The real world stays untouched — the operator controls what the `construct` contains.
That's exactly what jackin❯ does:
| Cyberpunk concept | jackin❯ |
| -------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Operator** | You — the developer running jackin❯ |
| **The `Construct`** | The base `Docker` image with system tools |
| **Jacking in** | `jackin load agent-smith` |
| **The agent inside** | Whatever runtime you load (`Claude Code`, `Codex`, `Amp`, `Kimi`, or `OpenCode` today), running at full speed |
| **The real world** | Your host machine, untouched |
| **Hardline** | `jackin hardline` — reconnecting to a running agent |
| **Pulling out** | `jackin eject` — stopping an agent |
| **Exile** | `jackin exile` — pulling everyone out at once |
Every command in jackin❯ maps to a cyberpunk-operator concept. This isn't just for fun — it makes the mental model intuitive. When you "load" an agent, you're loading it into a `construct`. When you "eject" it, you're pulling it out. The vocabulary reinforces what's actually happening.
## Why not just use Docker Sandboxes? [#why-not-just-use-docker-sandboxes]
Because the problem is not only isolation.
Products like [`Docker Sandboxes`](https://docs.docker.com/ai/sandboxes/) are strong at what they are designed for: quick-start agent sandboxes with a microVM boundary, a private `Docker` daemon, credential proxying for supported flows, and outbound network policy controls.
jackin❯ exists because many operators also want:
* agent environments they can define as normal source code
* explicit workspace objects with reusable mount layouts and access rules
* multiple role-specific roles against the same project
* an open tool they can extend instead of only consume
So the honest comparison is this:
* if you want the **strongest local isolation boundary**, `Docker Sandboxes` is ahead
* if you want **open, local-first agent orchestration**, jackin❯ is the better fit
For a deeper comparison, including adjacent approaches and where jackin❯ is weaker today, see [Comparison with Alternatives](/guides/comparison).
## What jackin❯ is NOT [#what-jackin-is-not]
* **Not a microVM today** — the current proof-of-concept boundary is the `Docker` container, not a hypervisor. If you need hypervisor-level isolation right now, use a microVM-based product such as `Docker Sandboxes`. Stronger boundaries — microVMs, alternative sandbox backends — are research items on the [Roadmap](/roadmap/); the long-term plan is to make the boundary configurable per workspace, not to force a single approach on everyone.
* **Not a sandbox for untrusted code execution** — it's for running *trusted agent runtimes* (`Claude Code`, `Codex`, `Amp`, `Kimi`, `OpenCode`) in a controlled environment. The agent binary itself is trusted; it's the agent's *actions* you want to contain.
* **Not Kubernetes** — jackin❯ runs on a single machine with `Docker`. Kubernetes support is on the roadmap for teams that need multi-node orchestration.
Both "not yet" points above are deliberate. jackin❯ starts with local `Docker` because that is the shortest path to an operator experience the team can iterate on. Over time, the same operator and workspace model can grow toward stronger sandbox backends and Kubernetes-backed debug workflows, but local development with the boundary we know best is the first job.
## Who is it for? [#who-is-it-for]
**Individual developers** who want to run AI agents at full speed without risking their host machine. You can give any supported runtime complete autonomy inside a container, knowing it can't accidentally delete your SSH keys or push to production. If you work on multiple projects or branches simultaneously, jackin❯ lets you run separate agents in parallel without resource pressure.
**Teams** that want to standardize how AI agents are deployed. Define role repos with the tools each project needs, save workspace configurations, and every developer gets the same isolated environment. Roles are git repos — version them, review them in PRs, share them across the organization.
**Agent developers** who want to build custom agent configurations. Create a Dockerfile with your preferred toolchain, declare it in a manifest, and anyone can load your agent with `jackin load`.
**Open source advocates** who prefer tools they can audit, modify, and contribute to. jackin❯ is built in Rust under Apache 2.0. When an AI agent has full autonomy inside an isolation boundary, being able to read and verify exactly how that boundary works is a meaningful advantage over proprietary alternatives.
## Why Rust? [#why-rust]
jackin❯ is built in Rust for three reasons:
1. **Performance and safety.** An orchestrator that launches and manages Docker containers, parses Dockerfiles, renders TUI interfaces, and handles concurrent agent state needs to be fast and correct. Rust's ownership model and `unsafe_code = "forbid"` policy mean jackin❯ has zero unsafe code and catches entire classes of bugs at compile time.
2. **Growing ecosystem.** Rust's adoption in infrastructure tooling, container runtimes, and CLI tools has accelerated significantly. The libraries jackin❯ depends on — `clap`, `ratatui`, `serde`, `dockerfile-parser-rs` — are mature and actively maintained.
3. **AI-friendly.** From practical experience, AI coding agents produce more reliable Rust code than most other systems languages. The strong type system and compiler feedback loop gives agents clear signals about what's wrong and how to fix it — leading to better AI-assisted contributions to the project itself.
## Current status [#current-status]
The core isolation model works, workspaces and mounts are configurable, the interactive operator console is functional, and the role system supports namespaced, team-shareable environments. It's licensed under Apache 2.0.
## Vision [#vision]
jackin❯ is designed as a **local-first development tool** focused on excellent UX and practical isolation. The near-term goal is to be the best way to run AI coding agents in parallel on a local machine — lightweight, composable, and open source. Every feature decision is weighed against that: does it make running many agents *on your laptop* more deliberate, more reusable, and more pleasant?
The longer-term vision extends to deployment ecosystems. **Kubernetes support** will let jackin❯ run as a debug-container platform — loading an agent into a production pod to safely investigate issues, with the same workspace and mount controls that make local use safe. The same operator and workspace primitives generalise from one laptop to one cluster; the boundary moves, the model stays the same.
Stronger isolation boundaries are an explicit research direction. Today the boundary is the `Docker` container. The roadmap tracks a **Docker runtime hardening contract** for profiles, DinD hardening, resource budgets, and launch-contract reporting; an **OrbStack isolated machine backend** for macOS operators who want a stronger local boundary while preserving Docker workflows; **smolvm backend research** for an open Rust/libkrun VM path; and **reproducibility/provenance pinning** so what runs is what was reviewed. The plan is to keep iterating on UX and ergonomics until jackin❯ is no longer in the *experimenting* phase, and then add stronger boundaries as configurable options per workspace — never as a single forced choice.
This vision is meant to be visible. Whether you arrived as an operator who wants to run their first agent, a role author building a `backend-engineer` role for your team, or a contributor deciding whether to send a PR — knowing where the project is going is part of the contract. The full design proposals, status, and order of operations live in the [Roadmap](/roadmap/).
If jackin❯ almost works for what you need but is missing something, the project welcomes suggestions and contributions: [open an issue](https://github.com/jackin-project/jackin/issues) or submit a pull request.