How do I set up a software development agent for sandboxed execution and git-based code reviews?

Here’s a practical way to set up a software development agent with sandboxed execution and git-based code reviews.

1) Choose the agent architecture

A good setup usually has 4 parts:

1. LLM agent
   Plans tasks, edits files, writes tests, summarizes changes.

2. Sandbox runner
   Executes code safely in an isolated environment.

3. Git workspace
   Each task runs on its own branch/clone.

4. Review/approval flow
   Agent opens a PR or patch; humans review diffs before merge.

---

2) Use a sandbox for all code execution

Recommended sandbox options

Pick one depending on your environment:

• Docker container: simplest and most common
• Firecracker microVM: stronger isolation, more complex
• Kubernetes job/pod: useful for scaling
• gVisor / Kata Containers: middle ground

Minimum Docker sandbox requirements

• Run as a non-root user
• Read-only base image where possible
• Mount only the working directory
• Disable privileged mode
• Limit CPU, memory, network, and disk
• Prefer no network access unless explicitly needed
• Auto-destroy container after task completion

Example docker run ideas:

docker run --rm -it \
  --network none \
  --cpus=2 \
  --memory=4g \
  --pids-limit=256 \
  -u 1000:1000 \
  -v "$PWD:/workspace" \
  -w /workspace \
  my-agent-image:latest

If the agent needs dependency installs, consider:

• building dependencies into the image beforehand
• allowing network only during a controlled setup phase
• caching packages outside the sandbox, then injecting them in a controlled way

---

3) Put the repo in a clean git-based workflow

Basic flow

1. Clone repo into a fresh working directory
2. Create a new branch for the task
3. Let the agent make changes
4. Run tests/lint in sandbox
5. Generate a diff
6. Open a PR or hand off a patch for review

Branching pattern

Use a consistent naming scheme:

agent/task-123-add-logging
agent/fix-456-null-pointer

Helpful git commands for the agent

git checkout -b agent/task-123
git status
git diff
git add -A
git commit -m "Implement task 123: add logging"

---

4) Make code review diff-centric

For reviews, the agent should produce:

• a short summary
• files changed
• tests run
• known limitations
• exact diff or PR link

Good review output format

Summary:
- Added request logging
- Added unit tests for error cases

Files changed:
- src/logger.py
- tests/test_logger.py

Validation:
- pytest passed
- lint passed

Notes:
- No network calls were added
- No database schema changes

Human review checklist

• Does the diff match the intended task?
• Are tests sufficient?
• Are there security regressions?
• Is the change minimal?
• Are docs/comments updated?

---

5) Enforce guardrails in the agent

Add policies like:

• Only modify files in the checked-out repo
• No shell access outside the sandbox
• No secrets access
• No direct pushes to main
• Require approval before merge
• Require test pass before PR creation

If the agent can use tools, expose only a narrow set:

• read file
• write file
• list directory
• run command in sandbox
• git diff
• git commit
• create PR

Avoid giving raw unrestricted shell or host access.

---

6) Recommended implementation pattern

Option A: Simple local setup

• Python agent orchestrator
• Docker for sandbox
• Git CLI for branching and diffing
• GitHub/GitLab API for PR creation

Option B: Team-scale setup

• Agent service
• Queue of tasks
• Ephemeral sandbox workers
• Central git server integration
• PR status reporting and audit logs

---

7) Minimal Python-oriented workflow

Pseudo-flow:

task = get_task()
repo_path = clone_repo(task.repo_url)
branch = create_branch(repo_path, task.id)

with sandbox(repo_path) as env:
    agent_plan = llm.plan(task)
    agent_edit_files(env, agent_plan)
    run_tests(env)
    diff = git_diff(env)
    create_pr(repo_path, branch, diff, summary)

---

8) Security tips

• Never mount your host home directory
• Don’t pass secrets into the sandbox unless unavoidable
• Use short-lived credentials for git access
• Log every command the agent runs
• Store artifacts and diffs for auditability
• Revoke network by default
• Scan generated code for suspicious behavior if needed

---

9) Good starting stack

If you want something practical and common:

• Agent: Python + OpenAI/LLM tool calling
• Sandbox: Docker
• Repo handling: git CLI
• Code review: GitHub PRs
• CI: GitHub Actions or GitLab CI

---

10) Example end-to-end process

1. User submits task
2. Orchestrator clones repo
3. Creates branch
4. Starts Docker sandbox
5. Agent edits code and writes tests
6. Runs tests/lint
7. Produces git diff
8. Opens PR
9. Human reviews and approves
10. Merge after CI passes

---

If you want, I can also provide:

• a reference Dockerfile + runner script
• a Python orchestration example
• a GitHub Actions review workflow
• or a production-ready architecture diagram