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 number and damage size from cybercrime reached $10.5 trillion, making it the third-largest economy in the world if it were a country.

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 YAML 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.yml 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.yml file. That’s your blueprint. It defines what your environment looks like and how it should behave.

Here is the most minimal example to get you going:

main:
  from: debian:bookworm
  workspace: workdir
  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: 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, create a scell.yml in your project root, and 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.