// openmonoagent.ai · isolation · BETA

Your agent doesn't
belong in your
shell.

Most coding agents run directly on your host machine. Every command, every file write, every package install happens in your actual environment. One hallucinated rm -rf and it's your system that pays.

OpenMono takes a fundamentally different approach.

Star on GitHub
// CONTAINER BOUNDARY ISOLATED
HOST MACHINE
openmono-agent
openmono CLI
git · ripgrep · python
MCP servers
/workspace (your project only)
openmono-network (internal)
llama-server
llama.cpp inference
port 7474 (internal only)
~/ home dir SSH keys other projects UNREACHABLE
// 01 · container boundary

The agent lives in
a disposable box.

When you launch OpenMono, the agent is confined to a Docker container. It doesn't live in your terminal or your shell — it's a separate, isolated process with its own filesystem and its own network stack.

docker/docker-compose.yml
services: agent: build: context: .. dockerfile: docker/Dockerfile.agent container_name: openmono-agent volumes: - ${WORKSPACE:-. }:/workspace # your project - ${HOME}/.openmono:/root/.openmono # config only environment: - OPENMONO_ENDPOINT=http://llama-server:7474 - OPENMONO_WORKSPACE=/workspace working_dir: /workspace   networks: default: name: openmono-network # private, internal
Physically impossible to escape

The container has its own filesystem root. There is no path the agent can write that reaches your home directory, your SSH keys, or any other project — the namespace boundary is enforced by the kernel.

Disposable by design

If the agent makes a mistake or trashes a config file mid-task, it happens inside a container. Stop it, start fresh. The damage stays inside the box.

Your home directory is invisible

The only mount into the container is your project directory — mapped to /workspace. Everything else on your machine is not mounted, not accessible, and not a risk.

// 02 · scoped filesystem

One project.
One room.

We mount your project directory into the container at /workspace. This gives the agent the surgical access it needs — read code, write files, execute builds — but nothing more.

"Think of it like hiring a contractor and giving them the keys to just one room. They have full autonomy to work in that space, but the rest of your house remains locked and unreachable."
Agent can access
  • /workspace/src/your source code
  • /workspace/*.slnsolution files
  • /workspace/tests/test suites
  • /workspace/docs/documentation
  • /root/.openmono/agent config
vs
Unreachable by the agent
  • ~/.ssh/your SSH keys
  • ~/.aws/cloud credentials
  • ~/Documents/personal files
  • ~/other-project/other repos
  • /etc/hostssystem config
// 03 · pre-baked toolchain

Zero clutter on
your machine.

The agent image comes pre-baked with the entire toolchain — the .NET runtime, git, ripgrep, Python, and the MCP servers for deep code analysis. You don't install any of it. It all lives inside the image.

docker/Dockerfile.agent
# Build stage — compile the CLI FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build COPY src/OpenMono.Cli/ src/OpenMono.Cli/ RUN dotnet publish ... -o /app   # Runtime stage — full toolchain FROM mcr.microsoft.com/dotnet/sdk:10.0 AS runtime RUN apt-get install -y \ git # version control ripgrep # fast code search python3 # scripting curl jq tree   # MCP servers for code analysis RUN pip3 install code-review-graph RUN pip3 install graphify   COPY --from=build /app /usr/local/bin/openmono/ WORKDIR /workspace ENTRYPOINT ["openmono"]
.NET SDK 10
The OpenMono CLI runtime. Compiled and embedded at build time.
git
Branch management, diff reading, commit operations — all inside the container.
ripgrep
Fast structural code search. The agent can grep your entire codebase without touching your host.
python3
For scripting, validation hooks, and running the MCP analysis servers.
code-review-graph
MCP server for structural code analysis. Call graphs, dependency maps — inside the sandbox.
graphify
Semantic knowledge graph queries over your codebase. Zero host footprint.
// 04 · network isolation

A closed circuit.
No internet. No LAN.

The agent talks to the LLM — running in its own llama.cpp container — over a private, internal Docker network. No internet exposure, no LAN access. It's a closed channel that only exists while the playbook is active.

openmono-agent
your project + tools
openmono-network :7474 (internal)
llama-server
local inference only
✕ internet
✕ LAN
✕ other containers
No outbound internet

The agent container has no route to the public internet. It cannot exfiltrate your code, call external APIs, or phone home. The network stack doesn't reach the WAN.

No LAN access

Your internal network — other machines, NAS drives, office servers — is equally invisible. The Docker network is a private overlay that spans exactly two containers.

Ephemeral channel

The network only exists while the containers are running. When the playbook completes, the network tears down. There is no persistent socket, no daemon, no residual exposure.

docker/docker-compose.yml — llama-server
llama-server: image: ghcr.io/ggml-org/llama.cpp:server ports: - "7474:7474" # only exposed if you explicitly open it healthcheck: test: ["CMD","curl","-f","http://localhost:7474/health"] interval: 10s volumes: - ../models:/models:ro # model weights, read-only
// 05 · the trust model

Why this level of
engineering matters.

The industry calls this YOLO mode. The reality is that hard isolation is the only thing that makes autonomous agents viable.

"Without a sandbox, you aren't using an agent — you're just a human rubber-stamping an LLM's suggestions."
Without isolation
  • Every tool call is a risk to your machine
  • You babysit every file write and shell command
  • One bad command can corrupt your environment
  • Agent mistakes are permanent and expensive
  • You can't let it run while you're away
With OpenMono isolation
  • Mistakes happen inside a disposable container
  • Stop it, start fresh — damage is gone
  • You don't verify every shell command for fear of system damage
  • Autonomy is real because the boundary is real
  • Actually unsupervised. Actually autonomous.
// THE OPENMONO TRUST MODEL
01
Local inference
The model runs on your hardware. Your code never leaves the machine.
02
Scoped filesystem
The agent gets your project. It gets exactly what it needs, and absolutely nothing else.
03
Network isolation
A direct line to the local model. Closed circuit. No internet. No LAN. No exposure.
// get started

Run it. Trust it.
Own it.

Local inference, scoped filesystem access, and network isolation. Install once and the agent works unsupervised — in a box it cannot escape.