Existing sandbox

Attach ALE to one already-running CUA-enabled machine. The static provider does not create, stop, reset, or delete the machine.

Debugging provider, not an isolated benchmark backend

Reusing one machine means state can carry between runs. Keep concurrency: 1, use a narrow task list, and reset the machine yourself when reproducibility matters.

When to use it

Iterating on a sandbox image without waiting for a fresh VM boot.
Reproducing one failed task against a machine you can inspect live.
Connecting ALE to a VMware, cloud, or local VM managed outside ALE.

For benchmark sweeps, use a managed provider that creates a fresh sandbox per run unit.

Requirements

A reachable CUA computer-server endpoint.
An OS and software stack that match the selected tasks.
Filesystem paths compatible with one registered ALE image family.
Task data already present in the sandbox, unless you configured another supported staging path yourself.

Configure the endpoint

Create a local environment file without committing machine addresses:

provider: static
endpoint: http://127.0.0.1:5000
image: ale-win10
vm_id: local-debug

task_data_source: baked_in_sandbox
output_path: local

image selects ALE's path conventions. It does not inspect or replace the machine image. Use ale-ubuntu22 for a compatible Linux sandbox or ale-win10 for a compatible Windows sandbox.

Optional cleanup script

The provider can run a command when a unit releases the sandbox, but it still does not restore a clean disk snapshot:

cleanup_on_release: true
cleanup_script: |
  powershell -NoProfile -Command "Remove-Item -Recurse -Force C:\Users\User\.ale\*"

Point an experiment at this environment file and follow Configure an experiment.