AI Agent Training & Evaluation Environment Version: 1 Base System: Windows 10 Pro Architecture: x86_64 Last Updated: May 2026 Developer: Kartik (NullVoider)
The Windows 10 Container is a complete Windows development environment designed for AI agent training, testing, evaluation, and deployment. It provides a full Windows desktop experience with pre-configured development tools, an integrated Task Executor REST API for coding agent evaluation, and screen capture monitoring—all within a single self-contained Docker container.
Purpose
This container is designed for:
Computer Use Agent Development: Pre-configured environment for building and testing CUA applications
Coding Agent Evaluation: Integrated Task Executor REST API (port 9090) for programmatic task submission, multi-framework test scoring, lint analysis, diff capture, and ground-truth patch similarity scoring.
Windows Development: Native Windows environment for developing Windows-specific applications
Automated Testing: Consistent, reproducible Windows environment for CI/CD pipelines
Remote Development: Full-featured Windows desktop accessible via RDP and VNC
Multi-Language Development: Support for 10+ programming languages out of the box
Visual Monitoring: Integrated Eye tool for screen capture and agent training data collection
What Makes This Unique
Single Container Design: Complete Windows 10 system with no external file dependencies
Ephemeral State: Everything is isolated inside the container, providing clean state management
Virtual Disk: 2TB of massive storage capacity.
RAM: Customizable memory allocation for smooth performance (minimum 4 GB for smooth experience).
Optimized Performance: Significantly smoother than existing Windows container alternatives
Fully Customizable: Configuration can be modified to improve performance based on hardware
Zero External Files: Everything is self-contained
Developer-Ready: Pre-installed IDEs, tools, and language runtimes
Task Executor API: REST API for programmatic coding agent evaluation (port 9090)
Multi-Framework Scoring: pytest, cargo, go test, jest, dotnet, JUnit — auto-detected and scored
Key Features
Operating System
✅ Windows 10 Pro - Latest releases
✅ Virtual Disk - 2TB of massive storage capacity.
✅ RAM - Customizable memory allocation for smooth performance (minimum 4 GB for smooth experience).
✅ Ephemeral State - Clean isolation with no external dependencies
Note: The virtual storage does not mandate requirement of exactly 2TB of storage in the device running the container. The virtual disk is a growable disk, and 2TB is the cap on the virtual disk.
Development Tools
✅ 10+ Languages - Python, Go, Rust, Java, C#, C++, Node.js, TypeScript, Kotlin, Scala
✅ VS Code - Pre-installed with essential extensions
✅ Visual Studio Build Tools - Windows development tools
✅ Git & Git LFS - Version control with large file support
✅ PowerShell & Terminal - Modern shell utilities
Applications
✅ Edge Browser - Default web browser
✅ VS Code - Feature-rich code editor
✅ Windows Terminal - Modern terminal experience
Remote Access
✅ RDP - Native Windows Remote Desktop (3389/TCP) - Recommended
✅ SSH - Secure shell access (2222/TCP)
✅ Eye Server - Screen capture endpoint (8080/HTTP)
✅ Task Executor API - Coding agent eval REST API (9090/HTTP)
Coding Agent Evaluation
✅ Task Executor REST API - Submit tasks, run tests, retrieve structured results
✅ Multi-Framework Test Scoring - pytest, cargo test, go test, jest, dotnet test, JUnit/Maven/Gradle/sbt
✅ Lint Integration - Soft-score linting via ruff, mypy, flake8, clippy, eslint, and more
✅ Diff Capture - Records agent-produced diffs after each task run
✅ Reference Patch Scoring - Ground-truth patch similarity (0.0–1.0) for patch-apply evals
✅ API Authentication - Optional bearer token auth via API_TOKEN env variable
Performance & Stability
✅ Fast Boot Time - Container ready in ~25 seconds
✅ Low CPU Usage - 10-20% under normal workload
✅ Smooth Performance - Optimized for regular development tasks
✅ Single Container - No external files or dependencies
✅ KVM Acceleration - Hardware virtualization for optimal performance
Container Capabilities
Operating System
Windows 10 Pro
Complete Windows desktop experience
Native Windows applications support
Standard NTFS file system
Windows security features
Native Windows APIs and frameworks
Storage Configuration:
Virtual Disk: 2TB capacity
Format: NTFS
RAM: Customizable as needed (minimum 4 GB for smooth experience).
1# Add your user to docker group (to run docker without sudo)2sudousermod -aG docker$USER34# Enable Docker service5sudo systemctl enabledocker6sudo systemctl start docker78# Log out and log back in for group changes to take effect
2. Enable KVM
Check KVM Support:
bash
1# Check if KVM is supported2lscpu |grep Virtualization
34# Check if KVM modules are loaded5lsmod |grep kvm
67# Expected output:8# kvm_intel (for Intel CPUs) or kvm_amd (for AMD CPUs)9# kvm
Enable KVM:
bash
1# Install KVM packages (Ubuntu/Debian)2sudoapt-getinstall -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils
34# For Fedora/RHEL/CentOS5sudo dnf install -y qemu-kvm libvirt virt-install bridge-utils
67# Verify KVM is working8sudo kvm-ok
910# Expected output:11# INFO: /dev/kvm exists12# KVM acceleration can be used
Set KVM Permissions:
bash
1# Add user to kvm group2sudousermod -aG kvm $USER34# Verify /dev/kvm permissions5ls -l /dev/kvm
67# Should show: crw-rw---- 1 root kvm89# Log out and log back in for group changes to take effect
Verify KVM Access:
bash
1# After logging back in, verify you can access KVM2groups|grep kvm
34# Test KVM device access5test -r /dev/kvm &&test -w /dev/kvm &&echo"KVM is accessible"||echo"KVM access denied"
If KVM is Not Enabled in BIOS:
Restart your computer
Enter BIOS/UEFI settings (usually F2, F10, F12, or Del key during boot)
Look for virtualization settings:
Intel: "Intel VT-x" or "Intel Virtualization Technology"
AMD: "AMD-V" or "SVM Mode"
Enable the setting
Save and exit BIOS
Boot into Linux and verify with kvm-ok
Docker Compose Deployment
Recommended Deployment Method: The ONLY recommended way to run this container is using Docker Compose. This ensures proper configuration and port mappings.
1# Stop the container2docker compose -f deploy-windows.yaml stop
34# Start the container5docker compose -f deploy-windows.yaml start
67# Restart the container8docker compose -f deploy-windows.yaml restart
910# Remove the container11docker compose -f deploy-windows.yaml down
1213# Remove container and volumes14docker compose -f deploy-windows.yaml down -v
Testing the Container
1. Verify Container is Running
bash
1# Check container status2dockerps|grep win_agent
34# Expected output:5# CONTAINER ID IMAGE STATUS PORTS6# abc123def456 nullvoider/win10-base:v1 Up 2 minutes 0.0.0.0:3389->3389/tcp, ...
2. Check Boot Progress
bash
1# Monitor container logs2docker logs -f win_agent
34# Look for successful boot messages indicating:5# - Windows boot sequence completed6# - Services started7# - RDP server ready
3. Test Remote Access
RDP (Recommended):
bash
1# From Windows host:2# Press Win+R, type: mstsc3# Connect to: your-server-ip:338945# From Linux host:6# Use Remmina, xfreerdp, or rdesktop7xfreerdp /v:your-server-ip:3389 /u:AgentUser
SSH:
bash
1# Test SSH connection2ssh -p 2222 AgentUser@your-server-ip
4. Verify Services
Once connected via RDP:
Open PowerShell or Command Prompt
Check system information: systeminfo
Verify development tools: python --version, node --version, etc.
Open VS Code to verify it's installed
5. Health Check
bash
1# Check container resource usage2docker stats win_agent
34# Expected metrics:5# CPU: 10-20% (normal workload)6# MEM: ~4GB allocated7# NET I/O: Varies based on remote access usage
Customizing the Image
This section walks through the full process of modifying the Windows 10 environment and rebuilding a custom Docker image — useful for adding languages, tools, updated scripts, or any workflow-specific configurations and customizations.
Prerequisites
Repository cloned
Docker and QEMU utilities installed (qemu-img must be on PATH)
At least 100 GB free disk space for the conversion steps
Step 1 — Modify the YAML Configuration (Optional)
If you need to adjust the RAM or CPU core allocation before booting into Windows 10, edit the YAML file inside the scripts/ directory of the cloned repo:
bash
1# Example: open and edit the YAML before moving it2nano scripts/win10.yaml
Then move it to a separate working directory of your choice — this directory will be your build workspace for all subsequent steps:
mv scripts/win10.yaml /your/working/directory/
⚠️ WARNING: Only change RAM and CPU core values in the YAML. Do not change the disk size — altering the disk size will corrupt data.img and make it unusable. If that happens, you will need to re-run Step 2 from the original QCOW2 file to start over.
Step 2 — Convert the QCOW2 to a Raw Image
From the root of the cloned repository, convert the QCOW2 disk image to a raw format that QEMU can use as a mutable disk:
qemu-img convert -p -f qcow2 -O raw win10-image/win10.qcow2 data.img
This may take several minutes depending on your disk speed. The -p flag shows progress.
Step 3 — Create the Windows 10 Directory Structure
Navigate to the working directory where you moved the YAML file and create the expected directory layout:
Copy or move the data.img produced in Step 2 into the directory you just created:
bash
1# Copy (safe — preserves originals)2cp /path/to/data.img windows10-storage/data.img
34# Or move (saves disk space if originals are no longer needed)5mv /path/to/data.img windows10-storage/data.img
Step 5 — Boot and Customize
Start the container from your working directory:
docker compose -f win10.yaml up -d
Connect via NoMachine or VNC and perform your customizations inside the running Windows 10 environment — updating the Task Executor script, installing apps, adding programming languages, configuring tools, or anything else your workflow requires.
Step 6 — Clean Up Before Capture
Before shutting down, ensure the Windows 10 environment is clean so no personal or session data ends up in your image:
Browser: Close all tabs and clear all browsing history, cookies, and cached data in every browser installed
Terminal: Wipe shell history — in the Powershell/Cmd terminal run Remove-Item (Get-PSReadlineOption).HistorySavePath
Recent items: Clear recent files, recent apps, and recent servers from file explorer quick access and app search.
Trash: Empty the Trash
Step 7 — Shut Down and Stop the Container
Shut down Windows cleanly from within the OS (Win Key → Power button → Shut Down or Alt+F4 → Shut Down) and wait for the guest to fully power off. Then, from the host terminal in your working directory:
docker compose -f win10.yaml down
Step 8 — Convert Back to QCOW2
From the windows10-storage/ directory, convert the modified raw image back to a compressed QCOW2:
The -c flag enables compression to keep the image size manageable. This step may take several minutes.
Step 9 — Move the QCOW2 to the Build Directory
Move the new QCOW2 back into the windows10-storage/ directory of the cloned repository. If a QCOW2 already exists there, remove it first:
bash
1# Remove existing if present2rm /path/to/cloned-repo/win10-image/win10.qcow2
34# Move new QCOW2 into place5mv windows10-storage/win10.qcow2 /path/to/cloned-repo/windows10-storage/win10.qcow2
Step 10 — Build Your Custom Image
From the root of the cloned repository, build the Docker image with your chosen tag:
The Eye is an AI-native vision capture tool integrated into the Windows container, providing automated screen capture capabilities for Computer Use Agent training, monitoring, and debugging.
Overview
The Eye captures screen content at configurable intervals for:
Agent Training: Collect visual data for training CUAs
Debugging: Record agent interactions for troubleshooting
Monitoring: Track agent behavior during execution
Dataset Creation: Build machine learning datasets from screen captures
Configuration
Eye Server Port: 8080 (HTTP) Architecture: Client-server model with RESTful API Storage: In-memory circular buffer (configurable capacity)
Connection & Endpoints
Eye Server Base URL:
http://your-server-ip:8080
Available Endpoints:
GET /health - Server health status and metrics
GET /snapshot.png - Retrieve latest captured frame
POST /upload - Upload captured frames (for external agents)
POST /admin/config - Update capture configuration
GET /debug - Server runtime statistics
Python SDK
The Eye includes a Python SDK for programmatic access:
Installation (if not using container's built-in Eye):
pip install eye-capture
Basic Usage:
python
1from eye.core import EyeClient
23# Connect to Eye server4client = EyeClient("http://localhost:8080", token="your-token")56# Health check7health = client.health_check()89# Get latest screenshot10image_data = client.get_snapshot()11withopen("screenshot.png","wb")as f:12 f.write(image_data)1314# Get frame metadata15metadata = client.get_snapshot_metadata()16print(f"Frame ID: {metadata['frame_id']}")1718# Get debug info19debug = client.get_debug_info()20print(f"Uptime: {debug['uptime_sec']}s")
The Task Executor (task_executor_windows.py, port 9090) is the evaluation harness for frontier coding agents running on the Windows environment. It provides a REST API for submitting coding tasks, running test suites inside isolated workspaces, optionally linting the result, capturing the agent's diff, and returning structured scores — all without requiring a human operator.
Each task lifecycle: clone a repository, check out a base commit, apply the agent's patch, run the test command, lint (optional), capture the diff, score against a reference patch (optional), clean up. Results are retrievable at any time via task ID.
Windows-specific implementation details:
Task workspace root: C:\Users\AgentUser\tasks\
Process tree termination on timeout: taskkill /F /T /PID — terminates all child processes, the Windows equivalent of POSIX SIGKILL on a process group
All git operations use list-form args (no shell interpolation) to prevent command injection
test_command and lint_command run with shell=True inside the container, which is expected for Windows command strings
Starting the Task Executor
Start the executor from PowerShell inside the container (via RDP or SSH):
powershell
1# With auth token and custom port2$env:API_TOKEN = "your-secret-token"3$env:API_PORT = "9090"4python C:\Users\AgentUser\task_executor_windows.py
Root directory for task workspaces and the executor log
API_PORT
9090
Port the Task Executor binds to
API_TOKEN
(unset)
Bearer token for all requests; auth disabled when unset
TASK_MAX_AGE
3600
Seconds after completion before task records are evicted from memory
Set these in the Docker Compose file under environment: or export them in the shell before starting the executor.
Authentication
When API_TOKEN is set, every request must include:
Authorization: Bearer <token>
Requests without a valid token return 401 Unauthorized. For isolated k8s pods with network-level access control, leave API_TOKEN unset to disable auth.
REST API Reference
POST /task/submit
Field
Type
Required
Description
repo_url
string
Yes
Git-clonable URL
test_command
string
Yes
Shell command run from repo root
base_commit
string
No
Commit/tag/branch to check out (default: HEAD)
patch
string
No
Unified diff applied via git apply
timeout
int
No
Seconds before process tree is killed (default: 300)
lint_command
string
No
CLI lint command; result is a soft score only
capture_diff
bool
No
Capture git diff <base_commit> after tests (default: false)
Removes the task record from memory. Does not cancel a running task — submit with a short timeout value to cancel effectively.
Supported Test Frameworks
test_command contains
Framework
pytest, py.test
pytest
cargo
cargo test
go test
go test
jest, npm test, yarn test, pnpm test
Jest
dotnet
dotnet test
mvn, gradle, sbt, junit
JUnit/Surefire
For unrecognised commands, all parsers are tried in order and the first non-zero result is used.
Supported Linters (Soft Score)
Linter
Language
Example lint_command
ruff
Python
ruff check . --output-format json
flake8
Python
flake8 src
mypy
Python
mypy src --ignore-missing-imports
pylint
Python
pylint src
cargo clippy
Rust
cargo clippy -- -D warnings
eslint
JS/TS
eslint src --format json
go vet
Go
go vet ./...
dotnet build
C#
dotnet build --no-restore
Lint results are always soft — lint_errors is recorded but never changes status or exit_code. This is consistent with the convention used by SWE-bench, HumanEval, and LiveCodeBench.
Remote Polling Pattern
python
1import time, requests
23BASE ="http://your-server-ip:9090"4HEADERS ={"Authorization":"Bearer your-secret-token"}56# Submit7r = requests.post(f"{BASE}/task/submit", headers=HEADERS, json={8"repo_url":"https://github.com/example/repo",9"test_command":"python -m pytest tests -x",10"lint_command":"ruff check .",11"capture_diff":True,12})13task_id = r.json()["task_id"]1415# Poll (5s interval is reasonable given Windows boot latency)16whileTrue:17 s = requests.get(f"{BASE}/task/{task_id}", headers=HEADERS).json()18if s["status"]notin("pending","running"):19break20 time.sleep(5)2122# Retrieve full result23result = requests.get(f"{BASE}/task/{task_id}/result", headers=HEADERS).json()24print(f"Passed: {result['tests_passed']} Failed: {result['tests_failed']} "25f"Lint: {result['lint_errors']} Similarity: {result['patch_similarity']}")2627# Clean up28requests.delete(f"{BASE}/task/{task_id}", headers=HEADERS)
Remote Access Methods
RDP (Recommended)
Primary Remote Access Method: RDP provides the best performance and native Windows integration.
Why RDP?
Performance Benefits:
Native Windows protocol
Hardware-accelerated rendering
Optimized for Windows GUI
Low latency input handling
Efficient bandwidth usage
Superior video quality
Features:
Full desktop experience
Audio support
Multi-session support
Printer redirection
Drive mapping
Connection Setup
From Windows Host:
Press Win + R
Type mstsc
Enter: your-server-ip:3389
Click Connect
From Linux Host:
bash
1# Using xfreerdp2xfreerdp /v:your-server-ip:3389 /u:AgentUser /smart-sizing
34# Using Remmina (Recommended)5remmina
67# Using rdesktop8rdesktop your-server-ip:3389
From macOS Host:
Download Microsoft Remote Desktop from App Store
Add PC: your-server-ip:3389
Connect
Best Practices
For Best Performance:
Use wired network connection when possible
Close unused applications in the container
Disable unnecessary visual effects in Windows settings
1# Open PowerShell as Administrator2Set-ItemProperty-Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU"-Name "NoAutoUpdate"-Value 1
34# Or use Services.msc5# Disable "Windows Update" service
1# Verify KVM is accessible2ls -l /dev/kvm
34# Check if you're in kvm group5groups|grep kvm
67# Add user to kvm group if missing8sudousermod -aG kvm $USER9# Log out and back in
Insufficient Resources:
bash
1# Check available RAM2free -h
34# Check disk space5df -h
67# Verify at least 4GB RAM available
Port Conflicts:
bash
1# Check if ports are already in use2sudonetstat -tlnp |grep -E '3389|4000|8080|9090|2222'34# Stop conflicting services or change ports in docker-compose.yaml
4. Remote Access Connection Issues
RDP Won't Connect:
bash
1# Verify port is exposed2docker port win_agent 338934# Check if service is listening5dockerexec win_agent netstat -an | findstr 338967# Test connectivity from host8telnet localhost 3389
SSH Connection Refused:
bash
1# Check SSH port mapping2docker port win_agent 222234# Verify SSH service5dockerexec win_agent powershell "Get-Service sshd"
5. Windows-Specific Issues
Standard Windows Troubleshooting Applies:
Most Windows-related issues can be resolved using standard Windows troubleshooting methods:
System Settings Reset:
Open Settings
Reset specific settings causing issues
Restart affected applications
Application Issues:
Use Task Manager to end unresponsive programs
Clear application caches
Disk Issues:
Run chkdsk
Check available storage space
Defragment if needed (though SSD doesn't need it)
Permission Issues:
Run applications as Administrator
Check file/folder permissions
Use icacls to fix permissions
These are standard Windows issues, not container-specific problems.
Getting Help
If you encounter issues not covered here:
Check container logs: docker logs win_agent
Review system resources: Ensure minimum requirements are met
Verify KVM access: Confirm /dev/kvm is accessible
Test connectivity: Check network and port accessibility
See Reporting Issues section for how to get support
CI/CD Integration
The Windows container is designed for seamless integration into CI/CD pipelines, particularly for Computer Use Agent development and deployment.
Supported Platforms
Container Orchestration:
✅ Docker - Native Docker deployment
✅ Kubernetes - K8s pod deployment
✅ Docker Compose - Multi-container orchestration
✅ Docker Swarm - Swarm service deployment
CI/CD Systems:
GitHub Actions
GitLab CI/CD
Jenkins
CircleCI
Travis CI
Azure DevOps
Any system supporting Docker
Docker-Based CI/CD
GitHub Actions Example
yaml
1name: Windows Tests
23on:[push, pull_request]45jobs:6test:7runs-on: ubuntu-latest
89steps:10-uses: actions/checkout@v3
1112-name: Set up KVM
13run:|14 sudo apt-get update
15 sudo apt-get install -y qemu-kvm libvirt-daemon-system
16 sudo usermod -aG kvm $USER1718-name: Start Windows Container
19run:|20 docker compose -f deploy-windows.yaml up -d
21 sleep 25 # Wait for boot2223-name: Run Tests
24run:|25 docker exec win_agent powershell -File tests/test_agent.ps12627-name: Cleanup
28if: always()
29run: docker compose -f deploy-windows.yaml down
GitLab CI Example
yaml
1stages:2- test
34windows_tests:5stage: test
6image: docker:latest
7services:8- docker:dind
9variables:10DOCKER_DRIVER: overlay2
11before_script:12- docker info
13script:14- docker compose -f deploy-windows.yaml up -d
15- sleep 25
16- docker exec win_agent powershell -File tests/test_agent.ps1
17after_script:18- docker compose -f deploy-windows.yaml down
19tags:20- kvm
Pass API_TOKEN as a k8s Secret — never hardcode in Compose files
General Hardening
Use NET_ADMIN capability only
Create a dedicated Docker network for agent containers
Use environment files or k8s Secrets for all tokens
Rebuild the image periodically to incorporate Windows updates
Enable Docker json-file logging with rotation
Only grant necessary permissions
FAQ
Coding Agent Evaluation Questions
Q: What is the Task Executor API?
A: It is a REST API (task_executor_windows.py) running on port 9090 that provides programmatic task submission, multi-framework test scoring, lint analysis, diff capture, and ground-truth patch similarity scoring. It is the primary eval harness for coding agents running on Windows.
Q: How do I start the Task Executor?
A: From PowerShell inside the container (via RDP or SSH): set API_TOKEN and API_PORT environment variables, then run python C:\Users\AgentUser\task_executor_windows.py. See the Task Executor API section for details.
Q: Why is lint scoring soft — why does it not fail the task?
A: The majority of established coding benchmarks (SWE-bench, HumanEval, LiveCodeBench) use test pass/fail as the primary correctness signal. Lint errors reflect code quality but not functional correctness. Keeping lint soft lets you track quality trends without invalidating otherwise correct solutions.
Q: What is patch_similarity and when is it useful?
A: It is a 0.0–1.0 similarity ratio between the agent's actual diff and a ground-truth reference patch, computed after stripping all unified diff metadata. Most useful for patch-apply evals where a canonical solution exists. Always interpret alongside tests_passed — a lower similarity score does not mean the solution is wrong.
Q: Can the Task Executor run tasks in parallel?
A: Yes. Each submitted task runs in an independent background thread with its own isolated workspace under TASK_BASE_DIR. For large-scale parallelism, deploy multiple container replicas via k8s — each replica maintains its own in-memory task store.
Q: What happens if a task times out?
A: The executor runs taskkill /F /T /PID, which forcefully terminates the entire process tree rooted at the test process. The task is marked failed with the timeout error recorded in stderr.
Q: How do I access the Task Executor remotely?
A: The Task Executor binds to 0.0.0.0:9090. In a k8s deployment, expose it via a ClusterIP service for internal orchestrator access, or NodePort/LoadBalancer for external access. Always set API_TOKEN when the port is reachable outside a trusted network boundary.
Q: In a k8s deployment with many replicas, how does an orchestrator route tasks to a specific container?
A: Each replica runs its own Task Executor with its own in-memory task store. Track the pod IP (or headless service DNS entry) at submission time and send all status/result polls to the same pod. A load-balanced service may route requests to different replicas and return 404 Task not found.
Q: What happens to in-flight tasks if a pod is evicted or restarted?
A: In-flight tasks are lost — the in-memory store does not survive a restart. Implement retry logic in your orchestrator and treat 404 Task not found as a signal to resubmit. The Windows container's ~25-second boot adds latency to recovery; account for this in orchestrator timeout settings.
Q: How do I pass API_TOKEN securely across a k8s cluster?
A: Mount it as a k8s Secret:
Never hardcode tokens in the Compose file or Dockerfile.
General Questions
Q: How is the entire Windows system running in a single container?
A: This container uses advanced virtualization techniques with KVM acceleration to run a complete Windows system. The implementation has everything self-contained within the container image. The result is a fully functional Windows 10 environment that's completely isolated and ephemeral.
Q: Why doesn't this container need external files?
A: The container architecture was designed from the ground up to be self-contained. All necessary components, including the Windows system files, bootloader, and configuration, are embedded within the container image itself. This provides significant advantages: easier deployment, cleaner state management, no external file dependencies, and true ephemeral operation.
Q: Can I run multiple instances of this container?
A: Yes, but each instance requires 4GB of RAM. Ensure your host has sufficient resources (e.g., 8GB+ RAM free for 2 instances).
Q: How much disk space does it need?
A: The container image requires approximately 100GB of host disk space. The Windows system inside has a 2TB virtual disk.
Q: Is this suitable for production use?
A: Yes, it's specifically designed for Computer Use Agent development, coding agents, and deployment in production environments. The container provides a stable, reproducible Windows environment ideal for CI/CD pipelines and automated testing.
Performance Questions
Q: Why is the boot time 25 seconds?
A: This includes the complete Windows boot sequence, service initialization, and remote access server setup. This is normal for a full Windows system and is competitive with bare-metal Windows boot times.
Q: Can I improve the performance?
A: Yes, the current host CPU configuration can be customized for better performance based on your hardware. The existing configuration prioritizes stability and compatibility. You can adjust the CPU configuration, though this requires testing on your specific hardware.
Q: Why does RDP perform better on Windows?
A: RDP is the native Windows remote desktop protocol and is optimized specifically for Windows GUI rendering. It uses hardware acceleration and efficient protocols designed for Windows systems.
Q: What's the CPU usage under heavy load?
A: Under normal development workloads (coding, browsing, terminal work), expect 20-30% CPU. Heavy compilation or resource-intensive applications may increase this to 40-50%.
Compatibility Questions
Q: Does it work on Windows/macOS hosts?
A: It requires a Linux host with KVM support. Windows (WSL2 with nested virtualization) and macOS hosts are not officially supported due to KVM requirements.
Q: What Linux distributions are supported?
A: Any modern Linux distribution with Docker 24.0+ and KVM support:
Ubuntu 20.04+
Debian 11+
Fedora 36+
CentOS 8+
Arch Linux
Q: Can I use AMD CPUs?
A: Yes, as long as AMD-V (SVM) is enabled in BIOS and the KVM kernel modules are loaded.
Q: What about ARM processors (Apple Silicon)?
A: Not supported. This is an x86_64 container designed for Intel/AMD processors only.
Configuration Questions
Q: Can I change the RAM allocation?
A: Yes, but currently the container is configured for 8GB RAM. Changing this requires rebuilding the container image with modified configuration.
Q: Can I use this for .NET development?
A: Yes, .NET SDK and Visual Studio Build Tools are pre-installed. The container is optimized for Computer Use Agent and Coding agent development but fully supports .NET workflows.
Q: How do I persist data across container restarts?
A: Use Docker volumes to mount directories from the host:
Q: Which remote access method should I use?
A: Use RDP for best performance — it is the native Windows protocol with hardware acceleration and full clipboard/audio support. Use SSH for headless command-line operations, script execution, and file transfers.
Q: Can I use other remote desktop solutions?
A: The container is pre-configured with RDP and VNC. Adding other solutions would require custom configuration.
Q: What's the bandwidth requirement for RDP?
A: Minimum 10 Mbps, recommended 100 Mbps+ for best experience. Less bandwidth will work but may impact video quality.
Troubleshooting Questions
Q: Windows Updates are interfering. What should I do?
A: Disable automatic updates via Group Policy or Services. See Troubleshooting section for detailed steps.
Q: Why is performance slow?
A: The host CPU configuration prioritizes stability. You can disable visual effects, unnecessary services, or customize the CPU configuration for better performance.
Q: The container won't start. What's wrong?
A: Check:
KVM is accessible (ls -l /dev/kvm)
Sufficient RAM available (8GB free)
Ports aren't conflicting
Docker service is running
Container logs for specific errors
Security Questions
Q: Is this container secure?
A: The container runs with NET_ADMIN capability and requires KVM access. It's designed for development environments. For production, review security considerations and implement appropriate network isolation.
Q: Can I run this in a public cloud?
A: Only on infrastructure that exposes hardware virtualization extensions to the guest. Bare-metal instances work universally. Standard VM instances require the cloud provider to explicitly enable nested virtualization — AWS Nitro, Google Cloud, and Azure support it on select instance types, but it must be enabled per-instance and is not on by default. The limiting factor is the hypervisor configuration, not the host OS.
Q: How do I secure remote access?
A: Use VPN or SSH tunneling to access the container:
ssh -L 3389:localhost:3389 -p 2222 host-server
Then connect RDP to localhost:3389.
License
This project is licensed under the GNU General Public License v3.0 (GPL-3.0).
What GPL-3.0 Covers
The GPL-3.0 license applies to:
Container configuration files and Docker Compose setup
Custom scripts and automation tools created by the developer
Integration code and custom components
Documentation and setup instructions
Any modifications you make to these components
GPL-3.0 License Summary
Permissions:
✅ Commercial use
✅ Modification
✅ Distribution
✅ Patent use
✅ Private use
Conditions:
📋 License and copyright notice
📋 State changes
📋 Disclose source
📋 Same license (copyleft)
Limitations:
❌ Liability
❌ Warranty
What This Means
For the Container Infrastructure (GPL-3.0):
You can use, modify, and distribute the container configuration
You can create derivative works of the setup scripts
This container is provided "as is" without warranty of any kind.
About This Project
The Windows 10 Container represents a significant advancement in containerized Windows environments. Built for Computer Use Agent development and frontier coding agent evaluation, this project addresses the key challenges faced by developers working with Windows-based automation and AI agents.
Version 1 extends the original CUA environment into a full coding agent evaluation platform. The Task Executor API — covering multi-framework test scoring, programmatic lint integration, diff capture, and ground-truth patch similarity scoring — was built to support rigorous coding agent benchmarking on a native Windows runtime, a capability absent from Linux-only eval frameworks.
Project Goals
Primary Objectives:
Provide a reproducible Windows environment for AI coding agents and CUA development
Eliminate external file dependencies for cleaner deployments
Optimize performance while maintaining stability
Enable seamless CI/CD integration for Windows workflows
Support scalable agent training and testing
Design Philosophy:
Self-Contained: Everything in one container, no external files
Ephemeral: Clean state management with proper isolation
Performant: Optimized for real-world development workflows
Tested: Based on confirmed safe and stable configurations
Accessible: Simple deployment with Docker Compose
Development Journey
This container was built from the ground up through:
Extensive testing on real hardware
Iterative performance optimization
Configuration tuning for stability
Integration of development tools
Refinement of remote access methods
Every configuration choice, from the host CPU setting to the 8GB RAM allocation, is based on tested and confirmed performance characteristics. The current configuration represents what can be safely delivered and has been verified to work reliably.
Why This Matters
For Developers:
Consistent Windows environment across team members
No "works on my machine" issues
Fast setup and deployment
Integrated development tools
Built-in monitoring capabilities
For Organizations:
Reproducible testing environments
CI/CD pipeline integration
Scalable agent deployment
Cost-effective Windows access
Clean resource management
Future Direction
While the current configuration is optimized for compatibility and stability, the container is designed to be customizable. As hardware capabilities evolve and use cases expand, configurations can be adjusted to leverage more powerful systems while maintaining the core benefits of containerization.
Acknowledgments
This project builds on the containerization ecosystem and the work of many in the Docker and virtualization communities. Special recognition to:
