Why jackin'?

The problem

AI coding agents are transforming software development. Tools like Claude Code, Codex, Amp Code, Kimi, and 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

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.

You define the boundaries

Which directories to mount, whether they’re read-only or read-write, what tools are available in the container image
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.
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

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

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?

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 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?

Because the problem is not only isolation.

Products like Docker 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.

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; 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?

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?

jackin’ is built in Rust for three reasons:

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.
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.
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

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

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.

If jackin’ almost works for what you need but is missing something, the project welcomes suggestions and contributions: open an issue or submit a pull request.