MicroVM Isolation & Security

Each Codex Cloud task runs in a dedicated microVM with strong isolation guarantees. The microVM has its own kernel, filesystem, network namespace, and process tree. No two tasks share memory, disk, or network state — even if they are from the same user. This isolation model means a malicious or buggy task cannot affect other tasks, other users, or the host infrastructure.

The filesystem inside a microVM starts as a clean clone of your repository. Codex installs dependencies based on your lock files, applies AGENTS.md rules, and then executes the task. When the task completes, only the diff (changed files) is preserved and made available for review. The microVM is destroyed — no state persists between tasks. This ephemeral model eliminates an entire class of security concerns: there is no persistent state to leak, no residual data from previous tasks, no accumulated configuration drift.

# MicroVM lifecycle

1. Task submitted → microVM provisioned (~3-5 seconds)
2. Repository cloned → dependencies installed
3. AGENTS.md loaded → configuration applied
4. Task executed → files modified, tests run
5. Results captured → diffs, logs, screenshots
6. MicroVM destroyed → no persistent state

# Isolation boundaries
- Separate kernel per task
- Separate filesystem per task
- Separate network namespace per task
- No shared memory between tasks
- No access to host filesystem

1. Verify isolation Run two cloud tasks simultaneously and confirm they cannot see each other's changes by checking the diff outputs independently.
2. Test dependency resolution Submit a cloud task and verify it installs the correct dependency versions from your lock file. Mismatched versions are the most common cloud-vs-local discrepancy.
3. Audit the diff Always review the full diff output, not just the summary. The microVM may generate files you did not expect (lock file updates, build artifacts).