Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/swe-agent/mini-swe-agent/llms.txt

Use this file to discover all available pages before exploring further.

An environment is the backend that actually executes the commands proposed by the agent. mini-swe-agent supports several environment backends ranging from direct local execution to fully isolated containers running in the cloud. Choosing the right environment depends on your use case. For exploratory local development, the default local environment is the simplest. For running benchmarks or untrusted code, container-based environments provide isolation that protects your host machine.

​
Available environments

local

Default. Runs commands directly on your machine using subprocess.run. No isolation.

docker

Runs commands inside a Docker container via docker exec. Good for SWE-bench and reproducible evaluations.

singularity

Runs commands in Singularity/Apptainer containers. Preferred on HPC clusters where Docker is unavailable.

bubblewrap

Linux-only lightweight unprivileged sandboxing via bubblewrap. Experimental.

swerex_docker

Docker execution routed through the SWE-ReX runtime layer.

swerex_modal

Modal cloud execution through SWE-ReX. Useful for running agents at scale with remote compute.

contree

ConTree platform — a sandboxed execution environment built for agents with Git-like execution semantics.

​
Specifying an environment

Pass the environment class via the CLI flag: 
mini --environment-class docker
Or set it in your YAML config file: 
environment:
  environment_class: docker
  image: swe-agent/swe-agent:latest
The --environment-class flag and the environment.environment_class key accept both short names (e.g., docker) and full import paths (e.g., minisweagent.environments.docker.DockerEnvironment).

​
Environment details

​
local

The local environment is the default when you run mini. It executes bash commands directly on your host machine using Python’s subprocess.run. There is no isolation — the agent has the same access to your filesystem and network that you do. Use when: interactive local development, quick experiments, or tasks where you are comfortable with the agent having full access to your environment. Prerequisites: none. 
environment:
  environment_class: local
  cwd: /path/to/working/directory   # optional: working directory
  timeout: 30                        # optional: command timeout in seconds

​
docker

The docker environment starts a container from a specified image and runs commands inside it via docker exec. The container is created at the start of the run and cleaned up afterward. Use when: SWE-bench evaluations, running untrusted code, or any time you want reproducible isolated execution. Prerequisites: Docker must be installed and running. 
environment:
  environment_class: docker
  image: sweagent/swe-agent:latest
  cwd: /                            # working directory inside the container
  timeout: 60                       # command timeout in seconds
  run_args:                         # extra args passed to docker run
    - "--rm"
    - "--memory=4g"
The Docker executable path defaults to docker. Override it with the MSWEA_DOCKER_EXECUTABLE environment variable if you use Podman or a custom Docker path.

​
singularity

The singularity environment runs commands in Singularity/Apptainer containers. It mirrors the Docker environment but uses the Singularity runtime instead. Use when: HPC clusters and environments where Docker is not available due to privilege requirements. Prerequisites: Singularity or Apptainer must be installed. 
environment:
  environment_class: singularity
  image: docker://sweagent/swe-agent:latest
Override the Singularity executable path with MSWEA_SINGULARITY_EXECUTABLE (default: singularity).

​
bubblewrap

The bubblewrap environment uses bubblewrap for lightweight, unprivileged sandboxing on Linux. It does not require root and does not spin up a full container. Use when: Linux systems where you want sandboxing without Docker overhead and without root privileges. Prerequisites: bubblewrap (bwrap) must be installed. Linux only.
The bubblewrap environment is experimental. Behavior may change in future releases.
environment:
  environment_class: bubblewrap
Override the bubblewrap executable path with MSWEA_BUBBLEWRAP_EXECUTABLE (default: bwrap).

​
swerex_docker

The swerex_docker environment routes Docker execution through the SWE-ReX runtime layer. It provides an interface compatible with SWE-ReX tooling on top of a local Docker backend. Use when: integrating with SWE-ReX pipelines or tooling that expects the SWE-ReX interface. Prerequisites: SWE-ReX must be installed (pip install swe-rex). Docker must be available. 
environment:
  environment_class: swerex_docker
  image: sweagent/swe-agent:latest

​
swerex_modal

The swerex_modal environment executes commands on Modal cloud infrastructure via SWE-ReX. This enables running agents at scale without managing local compute. Use when: large-scale evaluations, training data generation, or cloud execution where local resources are insufficient. Prerequisites: SWE-ReX must be installed with Modal support. A Modal account and API token are required. 
environment:
  environment_class: swerex_modal
  image: sweagent/swe-agent:latest

​
contree

The contree environment uses the ConTree platform for safe sandboxed code execution. ConTree is built specifically for coding agents and supports Git-like execution semantics. Use when: you want a managed, agent-oriented sandbox with branching execution. Prerequisites: a ConTree account and API access. 
environment:
  environment_class: contree

​
Startup commands

You can run a command inside the environment before the agent starts using run.env_startup_command. This is useful for setting up the workspace, installing dependencies, or configuring the environment. 
run:
  env_startup_command: "cd /repo && git checkout {{instance_id}}"
environment:
  environment_class: docker
  image: sweagent/swe-agent:latest
The env_startup_command supports Jinja2 templating with the same variables available in prompt templates, including any fields from the run config section.

Build docs developers (and LLMs) love

Get started for freeTalk to us