Building the execution environment for my minimal agent

I am building a small software-engineering agent to understand how it works and eventually evaluate it on SWE-bench. I started with the minimal-agent tutorial and use mini-swe-agent as a reference while writing my own implementation.

This stage was about giving the agent a consistent place to execute commands. Earlier, I started a Docker container manually and the agent ran commands inside it. I have now separated command execution into an environment object and added a runner that loads one task, starts its container, runs the agent, and attempts cleanup afterward.

The agent receives an environment instead of constructing one itself. DockerEnvironment runs commands inside a container. LocalEnvironment provides the same interface for local checks. The agent handles the conversation and translates execution errors into messages the model can respond to. The runner owns container startup and cleanup.

Working through this meant learning how subprocess argument lists are constructed and which environment variables belong to the host process versus commands inside Docker. Copying the old execution code into the startup method was not enough. Startup needs the container ID from stdout separately from diagnostics, while command execution combines output and errors for the agent to read.

One distinction was that stopping the host's Docker client does not necessarily stop the command running inside the container. The Docker environment now applies a timeout inside the container as well as a longer host-side limit. It passes partial output back when a command times out.

Cleanup also needed more care than simply clearing the stored container name. I revised it to retain that information if removal fails, so there is still a way to retry or identify the container. The runner uses try/finally to attempt cleanup even if the agent encounters an error.

Claude ran targeted checks during our review. In one Docker check, a command printed partial output and then slept. It timed out after about three seconds, preserved that output, and a subsequent process check found no remaining sleep command from that test.

Another check used a substitute agent with a real Docker container to exercise task loading, execution, the returned record, and cleanup without making a model call. I also ran the real agent afterward. These checks establish specific pieces of the execution workflow. They do not establish a SWE-bench score.

I use Claude Code as a learning assistant. I ask for skeletons, pseudocode, explanations, and reviews, then fill in implementations myself. Claude has also supplied detailed guidance and run some checks. Questions about instance state, subprocess arguments, and exception handling have been part of building this version.

As of October 15, configuration loading is the next step. Saving patches and run records, automatic scoring, and a complete benchmark run are still ahead. The goal is to account for successful attempts, unsuccessful attempts, and execution failures across the chosen benchmark collection.