---
title: "CodeCourier: Running Untrusted Code Without Getting Burned"
description: "CodeCourier executes AI-generated code in isolated sandboxes so a bad snippet can never touch the host. Here is what I learned about safe code execution."
type: "build"
locale: "en"
category: "tool"
canonical: "https://agenticschool.dev/builds/codecourier"
dateModified: "2026-06-12"
---

# CodeCourier: Running Untrusted Code Without Getting Burned

- Category: tool
- Status: internal
- Stack: Node.js, E2B, Docker, TypeScript, REST API
- Updated: 2026-06-12
- Keywords: sandbox, code execution, E2B, security, untrusted code
- Canonical URL: https://agenticschool.dev/builds/codecourier
- Locale: en

> Executing AI-generated code safely, in a sandbox that can blow up.

CodeCourier executes AI-generated code in isolated sandboxes so a bad snippet can never touch the host. Here is what I learned about safe code execution.

## The problem with running code an AI wrote

The moment you let an AI generate code and then run it, you have a security problem. The code might be fine, or it might delete files, leak secrets, or hammer the network. CodeCourier was my answer: a service that takes a snippet, runs it somewhere it can do no harm, and returns the result.

## Sandboxes are the whole point

The core idea is that the code runs in a disposable, isolated environment, a sandbox, that has no access to anything I care about. If a snippet tries something nasty, the worst case is that the sandbox gets thrown away. I leaned on existing sandbox infrastructure rather than rolling my own isolation, because getting isolation subtly wrong is how you get owned.

- Each run gets a fresh, throwaway environment with no host access and no real secrets.
- Network and filesystem are locked down by default; you grant access deliberately, never accidentally.
- Timeouts and resource limits stop a runaway snippet from costing you money or hanging forever.

## Why I did not build my own isolation

My instinct was to clever my way to a homemade sandbox. I am glad I did not. Isolation is a domain where the failure mode is silent and catastrophic: you think you are safe until you are very much not. Using purpose-built sandbox tooling meant the hard, security-critical part was handled by people who specialise in it, and I got to focus on the orchestration around it. That is the same instinct as using an auth provider instead of rolling your own login: some problems are too sharp to solve from scratch.

## Lessons learned

- Never run untrusted or AI-generated code on a machine you care about. Always sandbox it.
- Default to locked-down. Grant network and filesystem access deliberately, never by accident.
- Do not roll your own isolation. Security-critical primitives are where you stand on the shoulders of specialists.
- Timeouts and resource caps are not optional. A sandbox without limits is just a slower way to get hurt.