AI coding safety

Full Access Without Full Blast Radius

This guide explains how to run an AI coding agent with broad permissions while preventing one mistaken command from reaching an entire home directory, unrelated repositories, production databases, or cloud resources. It combines Codex configuration, global agent instructions, Docker isolation, dedicated operating systems, cloud development machines, Git recovery, and production access controls. Start with the summary, then select the isolation model that matches the development platform.

Audience

Developers using AI agents in VS Code or a terminal

Primary pattern

Full Access inside a disposable development boundary

Recovery model

Git remote plus independent backups

Introduction

AI coding agents execute real commands. A model can misunderstand an ambiguous request, construct the wrong path, repurpose a sensitive environment variable, or clean up more than intended. The command may be syntactically valid and still be catastrophically wrong.

One dangerous pattern involves treating $HOME as a temporary location. If cleanup logic later targets the wrong value, the result can be deletion of a user profile instead of a disposable directory. The production equivalent is an agent holding credentials that permit DROP, TRUNCATE, destructive migrations, storage deletion, or cloud-resource removal.

The solution is not a better sentence in a prompt. Durable instructions help, but a reliable design also limits what the process can reach.

Why Full Access changes the risk

Codex defines danger-full-access as operation without the normal filesystem and network sandbox boundaries. Combining it with approval_policy = "never" removes the ordinary approval pause as well. OpenAI documents the lower-risk local automation combination as workspace-write with on-request approvals.

# High-risk on a personal workstation
approval_policy = "never"
sandbox_mode = "danger-full-access"

# Lower-risk host default
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review" # or "user"

A second high-risk pattern is opening the entire home directory as the trusted project root. That turns unrelated repositories, downloads, documents, local databases, credentials, and application state into neighboring files from the agent’s perspective.

The layered defense

Layer	Purpose	Limitation
Global instructions	Define destructive-action behavior and remove ambiguous authorization.	Guidance is not an operating-system boundary.
Codex sandbox and approvals	Restrict routine host access and pause boundary crossings.	Full Access intentionally removes much of this protection.
Docker or a VM	Reduce the reachable filesystem and process environment.	Mounted files and exposed credentials remain reachable.
Git and independent backups	Recover tracked work after deletion or corruption.	Uncommitted and untracked work requires separate protection.
Production identity controls	Prevent local coding tools from obtaining destructive production authority.	Broad administrator credentials defeat this layer.

Layer 1: durable global instructions

Keep the narrow invariant in the global Codex configuration. It applies across repositories and reinforces the specific failure mode.

developer_instructions = """
Never assign to or override `$HOME`; use a dedicated temporary variable instead.
"""

Place the broader destructive-operation protocol in the global ~/.codex/AGENTS.md file:

# Global AI Agent Safety Instructions

## Destructive Ambiguity Protocol

Requests such as “delete it,” “reset it,” “clean it up,” “wipe it,”
“start over,” “restore the environment,” “remove everything,”
“drop it,” “truncate it,” or “do whatever is needed” are not
authorization for destructive or irreversible actions.

Before any destructive or potentially irreversible operation, explain:

- The exact proposed action.
- The exact target.
- Why the action is necessary.
- What data, state, access, history, or resources could be lost.
- Safer alternatives.
- The exact command, API request, tool call, or file operation.

Ask for explicit confirmation and wait before proceeding.

Broad approval such as “fix it,” “go ahead,” or “do what you need”
is not sufficient authorization for destructive work.

For production systems, databases, backups, secrets, credentials,
cloud resources, home directories, or anything outside the current
repository, stop and request explicit confirmation before any
destructive or potentially irreversible operation.

Never assign to or override `$HOME`; use a dedicated temporary
variable instead.

Temporary cleanup code can make the permitted path explicit:

tmp_root="${TMPDIR:-/tmp}"
tmp_dir="$(mktemp -d "${tmp_root%/}/agent-task.XXXXXX")"

# Work only inside "$tmp_dir".

case "$tmp_dir" in
  "${tmp_root%/}"/agent-task.*) rm -rf -- "$tmp_dir" ;;
  *) echo "Refusing cleanup outside the dedicated temp root" >&2; exit 1 ;;
esac

Layer 2: Full Access inside Docker

The practical containment model gives Codex Full Access inside a Linux container while withholding the host home directory, Docker control socket, unrelated repositories, personal credentials, and production credentials.

Developer Mac or workstation
├── Real home directory                    not mounted
├── Canonical repositories                 not mounted in volume mode
├── SSH keys, cloud profiles, Keychain     not mounted
├── Production credentials                 not injected
└── Docker Desktop / Docker Engine
    └── Dev container
        ├── Disposable container home
        ├── One repository clone or volume
        ├── Development-only credentials
        └── Codex Full Access inside this boundary

Docker namespaces create the outer isolation layer. The boundary remains meaningful only when host resources are not reintroduced through mounts, privileged mode, the Docker daemon socket, or broad credentials.

Container rules

• No mount of $HOME, ~/.ssh, cloud CLI profiles, password stores, or unrelated source directories.
• No /var/run/docker.sock mount. Access to the Docker daemon can provide control over other containers and host-mounted data.
• No --privileged container.
• A normal non-root development user inside the container.
• Only development or test credentials, each with the narrowest practical scope.
• One project clone or Docker volume per trust boundary.

Separate host and container configurations

The host keeps the lower-risk default. A separate ~/.codex/config.toml inside the container can enable Full Access because the container, not the workstation, is now the outer boundary.

# Inside the isolated container only
sandbox_mode = "danger-full-access"
approval_policy = "never"

developer_instructions = """
Never assign to or override `$HOME`; use a dedicated temporary variable instead.
"""

Do not mount the workstation’s ~/.codex directory into the container. A container-specific Codex home prevents deletion of host sessions and configuration, and it keeps host credentials outside the agent’s filesystem.

Layer 3: the VS Code daily workflow

VS Code’s Dev Containers extension keeps the editor experience familiar. The window runs on the workstation, while extensions, terminals, language servers, builds, and the agent run in the container.

1. Install Docker Desktop or Docker Engine and the VS Code Dev Containers extension.
2. Run Dev Containers: Clone Repository in Container Volume from the Command Palette.
3. Select the repository and open the resulting container workspace.
4. Install Codex inside the container and authenticate with a dedicated development identity.
5. Keep Full Access confined to that container session.
6. Commit and push the working branch regularly.
7. Rebuild or discard the container when its state becomes questionable.

A minimal .devcontainer/devcontainer.json can remain intentionally small:

{
  "name": "isolated-ai-workspace",
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "containerEnv": {
    "TMPDIR": "/tmp"
  },
  "runArgs": [
    "--security-opt=no-new-privileges:true"
  ]
}

The repository-in-volume command matters. Opening a normal host folder and selecting Reopen in Container commonly creates a writable bind mount. Docker documents that a read-write bind mount permits container processes to modify or delete the corresponding host files.

Choosing a storage model

Model	Daily experience	Deletion exposure	Recovery
Host bind mount	Files remain directly visible in Finder or Explorer.	The mounted repository can be changed or deleted from the container.	Git remote, host backup, or a fresh clone.
Container volume clone	Files remain fully visible in VS Code while attached.	The volume can be deleted, but the canonical host home and repositories remain outside.	Push branches; optionally export the volume.
Disposable clone per task	More setup and branch synchronization.	Smallest practical development blast radius.	Push a branch or transfer a reviewed patch.

Backups without treating Docker as the source of truth

A named volume persists independently of an individual container, but persistence is not the same as backup. The durable source of truth remains a remote Git repository plus an independent backup system.

• Commit meaningful checkpoints throughout the day.
• Push feature branches before long autonomous runs.
• Protect the default branch from force pushes and direct deletion.
• Export or snapshot Docker volumes when valuable uncommitted or untracked work remains overnight.
• Keep at least one backup destination inaccessible to the agent session.
• Exclude secrets, generated credentials, and database dumps from Git.

Production databases and cloud resources

Docker protects local files; it does not neutralize credentials. An agent inside a container can still reach a production API or database when network access and destructive credentials are available.

A safer production boundary contains all of the following:

• No production administrator credentials in the development container.
• No production database role capable of DROP, TRUNCATE, privilege changes, backup deletion, or unrestricted migrations.
• A separate read-only identity for rare diagnostic access.
• Production changes executed through CI/CD with reviewed code, an explicit approval gate, and a recorded audit trail.
• Database backups and point-in-time recovery configured independently of the agent.
• Cloud deletion protection and resource locks where the platform provides them.
• Separate accounts for development automation and production administration.

The simplest test is direct: if the agent can authenticate to production and run a destructive command, the production boundary is incomplete.

When Docker is not enough

Docker is an effective boundary for Linux-compatible development, but some projects require native operating-system tooling, device access, signing systems, desktop automation, or kernel-level integration. A dedicated operating-system installation, local virtual machine, or cloud development machine preserves those capabilities without exposing the primary personal workstation.

Boundary	Best fit	Main benefit	Remaining exposure
Docker container	Web, backend, data, CLI, and cross-platform repositories	Fast rebuilds and a small filesystem boundary	Mounted files, injected credentials, and reachable networks
Local virtual machine	Windows or Linux native tooling and resettable test environments	Independent OS, filesystem, users, and snapshots	Shared folders, clipboard integration, host credentials, and network routes
Dedicated boot disk	Native macOS, Windows, or Linux work requiring real hardware access	Complete native toolchain with personal disks kept offline	Any disk, identity, credential, or service unlocked inside the development OS
Coding-only cloud machine	Remote development, disposable environments, and team-standard workstations	No direct access to the developer’s local disks	Cloud identity, network connectivity, and any secrets assigned to the machine
Separate physical computer	Native development with the largest practical separation	Independent hardware, storage, accounts, and operating system	Shared cloud accounts, removable media, and production credentials

Common dedicated-system baseline

The same baseline applies to macOS, Windows, and Linux:

1. Install a clean operating system on a dedicated disk or create a dedicated virtual machine.
2. Create a standard non-administrator account for daily coding.
3. Keep a separate administrator account for operating-system maintenance and tool installation.
4. Enable full-disk encryption, automatic security updates, the host firewall, and platform malware protections.
5. Keep personal disks encrypted, locked, offline, or unmounted during agent sessions.
6. Keep personal sync accounts, password managers, browser profiles, messages, photos, and consumer cloud storage out of the development system.
7. Create separate development identities and narrowly scoped repository tokens.
8. Keep production credentials and production network connectivity outside the development environment.
9. Commit and push regularly; snapshots cover unfinished work but do not replace Git.
10. Rebuild the environment after unexplained destructive behavior or suspected compromise.

A separate cloud identity protects synced data and account scope. A separate local operating-system account limits local permissions. A dedicated disk or VM separates files and system state. These controls solve different problems and work best together.

macOS

macOS can be installed on a compatible external or additional internal storage device and selected as the startup disk. This provides native Objective-C, Swift, Xcode, simulator, signing, TCC, Accessibility, Screen Recording, and /Applications behavior without placing the primary macOS installation in the same writable environment.

• Enable FileVault on the development volume.
• Keep the primary internal volume locked or unmounted while booted into the development system.
• Run daily development from a standard account and retain a separate local administrator account.
• Leave personal iCloud, Photos, Messages, Keychain synchronization, and personal browser profiles disconnected.
• Add a dedicated development Apple Account only when App Store access, Apple services, or signing workflows require it.
• Keep signing certificates and provisioning material limited to the development environment and project role.

For native Apple builds in the cloud, the environment still needs Mac hardware. A Mac cloud provider or Amazon EC2 Mac can supply a remote macOS development host; an ordinary Windows or Linux VM cannot run Xcode.

Windows

Windows development can run from a dedicated SSD installation, a Hyper-V virtual machine, or a cloud Windows workstation. Hyper-V is designed for development and testing scenarios and gives the guest a separate operating system and virtual disk.

• Enable BitLocker or device encryption on development and personal volumes.
• Run VS Code and the agent from a standard Windows account with User Account Control enabled.
• Keep the administrator account separate and sign in only for maintenance.
• Do not attach personal drives, OneDrive libraries, browser profiles, Windows credentials, or broad PowerShell secrets to the development VM.
• Disable shared folders and clipboard transfer when they are not required.
• Keep Windows Security, the firewall, Secure Boot, and updates enabled.

Linux

Linux development can run from a dedicated encrypted installation, KVM/QEMU virtual machine, or cloud Linux VM. Linux Unified Key Setup provides block-level full-disk encryption, while AppArmor or SELinux can add process-level restrictions beyond normal user permissions.

• Enable LUKS or the distribution’s full-disk encryption during installation.
• Run the agent as a normal user without passwordless sudo.
• Keep personal partitions and removable backup disks unmounted.
• Store repository credentials in a development-only key or token with narrow scope.
• Enable the distribution firewall, automatic security updates, and the available mandatory-access-control system.
• Keep production SSH keys, Kubernetes contexts, cloud profiles, and database credentials off the machine.

Coding-only cloud workstations

A cloud development machine moves the entire coding environment away from local personal storage. Suitable options include Azure Virtual Machines, Microsoft Dev Box or Windows 365 development workstations where available, Amazon EC2, Amazon EC2 Mac for native macOS work, Google Compute Engine, and comparable managed development environments.

Cloud boundary requirements

• A separate cloud subscription, account, project, or resource group for development workstations.
• No virtual-network peering, private route, VPN, service endpoint, or private DNS path into production unless a narrowly reviewed workflow requires it.
• No production managed identity, service principal, access key, database password, Kubernetes context, or administrator token.
• Repository credentials limited to the repositories required for development.
• Inbound management access through a controlled path such as Azure Bastion, just-in-time access, a VPN, an identity-aware proxy, or a provider-managed remote desktop.
• Default-deny network rules with only the development endpoints required by the project.
• Automatic shutdown or deallocation outside working hours.
• Short-lived machines rebuilt from versioned images or setup scripts.
• Git as the source of truth, with snapshots only for unfinished work and rapid recovery.
• Central audit logs for sign-ins, privilege changes, network-rule changes, and resource deletion.

The cloud VM is not a bridge into production. Source code reaches production through reviewed CI/CD, deployment identities, and explicit release approvals rather than credentials stored on the coding machine.

If deletion has already happened

1. Stop the agent and any related automation immediately.
2. Disconnect production credentials and revoke active tokens when exposure is possible.
3. Do not run cleanup, reinstall, or repair commands over the affected storage before recovery assessment.
4. Preserve the agent transcript, terminal history, audit logs, and exact commands.
5. Recover tracked source from the remote repository.
6. Recover untracked files from snapshots, workstation backups, or volume exports.
7. For production data loss, follow the database or cloud provider’s incident and point-in-time recovery process with an experienced operator.
8. Rotate credentials and review every system reachable from the original session.

Launch checklist

• The workstation defaults to workspace-write and interactive or automatic review.
• Full Access runs only inside a container or VM.
• The home directory is not a trusted project root.
• The global AGENTS.md contains a destructive-action confirmation protocol.
• $HOME is never repurposed as a temporary variable.
• The container has no host home, SSH directory, cloud profile, or Docker socket mount.
• The repository exists in a dedicated volume or disposable clone.
• Native tooling runs in a dedicated OS, VM, or separate development machine rather than the primary personal environment.
• Cloud coding machines have no production credentials or network route.
• Important work is committed and pushed before long autonomous runs.
• No destructive production credential exists inside the development environment.
• Backups remain outside the agent’s writable reach.

Sources

• OpenAI: Codex sandboxing and permission modes
• OpenAI: Auto-review behavior and limits
• OpenAI: Global and project AGENTS.md guidance
• Visual Studio Code: Developing inside a container
• Visual Studio Code: Dev Containers tutorial
• Docker: Bind mounts and host-file access
• Docker: Persistent volumes
• Docker: Engine security and isolation
• Docker: Protecting access to the Docker daemon
• Apple: Using external storage as a Mac startup disk
• Apple: FileVault disk protection
• Apple: Administrator and standard local accounts
• Microsoft: Hyper-V for development and testing
• Microsoft: Windows user-account separation
• Microsoft: User Account Control
• Microsoft: Cloud development workstations with Dev Box
• Microsoft: Just-in-time access for Azure VMs
• Microsoft: Azure network security groups
• Ubuntu: LUKS full-disk encryption
• Ubuntu: AppArmor process restrictions
• Amazon Web Services: EC2 Mac development hosts
• Google Cloud: Compute Engine virtual machines