Containerized shell sessions with Shell-Cell
It’s beginning of 2026.
The madness is on fire around AI, Agents and what all of this is capable of doing.
There was not a single week during 2025 without any news about some new AI-related application release.
Pretty much every CEO of a big tech company considers it his duty to say that AI either writes ALL CODE for their application or it is near to be so.
OpenAI launching ADS in the ChatGPT, meaning the amount of your personal data which would be used by these hyperscalers would be enormous. So that Meta with Facebook would look like an innocent baby.
The cybercrime projected damage size for 2025 is $10.5 trillion and to be a $12.2 trillion by 2031 https://cybersecurityventures.com/official-cybercrime-report-2025/.
During your regular day-to-day development, you have to be careful about what code you are compiling on your machine
(A good post about that issue for the Rust ecosystem).
There is a new threat and attack vector - prompt injection, agent hijacking etc.
Sounds crazy, isn’t it? 🤪
With all these thoughts in mind and probably with some paranoia that I could be hacked, I realized that I want a secured terminal environment, where I would work with the code, run applications. Without worrying about that I am giving to some tool (which I need to run) too much access on my machine.
And to be honest everything that is needed already exists, and the answer for it is - container! I want to run a shell session as a separate container!
That’s how a new CLI tool Shell-Cell was born.
What the hell is Shell-Cell?
By taking great architectural ideas from different tools which I’ve been using through my professional career, I came up with a simple concept.
What if you could describe your entire development environment in a single CUE file, and with one command — just drop into a fully isolated shell session inside a container?
Just write a blueprint, run scell, and you are in.
That’s exactly what Shell-Cell does. It is a lightweight CLI tool that reads a scell.cue blueprint, compiles it into an image, and launches a persistent container — a shell server. You can then attach one or multiple interactive shell sessions to it, and your environment and its state just stays there,
warm and ready.
The blueprint
Everything starts with the scell.cue file. That’s your blueprint, written in the CUE language. It defines what your environment looks like and how it should behave.
Here is the most minimal example to get you going:
main: {
from_image: "debian:bookworm"
workspace: "/app"
shell: "/bin/bash"
hang: "while true; do sleep 3600; done"
}
That’s it. Four lines and you have a containerized shell session based on Debian.
If you want a more real-world example with the Rust compiler, Claude Code and mounting your host project directory ./ to the container workspace directory my_app, here we go:
main: {
from_image: "rust:1.93-trixie"
env: [
// claude code installation path
"PATH=\"/root/.local/bin:$PATH\"",
]
build: [
"apt-get update --fix-missing",
"apt-get -y install git curl wget",
// claude code
"curl -fsSL https://claude.ai/install.sh | bash",
// zsh
"apt install -y zsh",
]
workspace: "my_app"
shell: "/bin/zsh"
hang: "while true; do sleep 3600; done"
config: {
mounts: [
"./:/my_app/",
]
}
}
How to get started
You need either Docker or Podman running on your machine. Then install Shell-Cell:
curl -fsSL https://github.com/Mr-Leshiy/shell-cell/releases/latest/download/shell-cell-installer.sh | sh
Or if you are a Rust developer:
cargo install shell-cell --locked
After that, run scell init to generate a minimal scell.cue in your project directory:
scell init
Or write one by hand. Then run:
scell
That’s it. First run builds the image and starts the container. Every next run just attaches a new shell session to the already running container. Fast, warm, and isolated.
Why bother?
Actually, you could achieve something similar with raw docker run commands, Dockerfiles, and shell scripts. But that’s exactly the point — you shouldn’t have to.
Shell-Cell gives you a dead simple, declarative way to define isolated environments. One file. One command. And you are in a secure sandbox where you can compile untrusted code, run AI agents, or experiment with random tools from the internet — without giving them the keys to your actual machine. Or do your own stuff, run your own use case which I can’t imagine!
The project is still under active development, so expect breaking changes. But the core idea is solid, and I am already using it daily for my projects.
Interested? Here is detailed documentation. Still have an unanswered question? Join the Discord community.