Skip to main content

Execution

Execution configuration defines where and how AgentGate runs agent tasks. It specifies the code workspace, sandbox isolation, and agent runtime settings.

What Is Execution

The execution section of a TaskSpec controls three key aspects:
ComponentPurpose
WorkspaceWhere the code lives (local, git, GitHub)
SandboxIsolation and resource limits (Docker, subprocess)
AgentAI driver configuration

Execution Specification

spec:
  execution:
    workspace:
      source: github
      owner: myorg
      repo: myproject
      ref: main

    sandbox:
      provider: docker
      image: node:20
      resources:
        cpu: 2
        memory: "4Gi"
        timeout: "1h"
      network: bridge

    agent:
      driver: claude-code-subscription
      model: claude-sonnet-4-20250514
      maxTokens: 200000

Workspace Types

AgentGate supports five workspace types for different scenarios:
Use an existing local directoryWork directly on an existing codebase:
workspace:
  source: local
  path: /path/to/project
  readonly: false  # Optional: prevent writes
Options:
OptionTypeDescription
pathstringAbsolute path to the workspace
readonlybooleanPrevent file modifications (testing)
Best for:
  • Local development and testing
  • Existing projects on the machine
  • Quick iterations without git operations

Sandbox Configuration

Sandboxes provide isolation and resource control for agent execution:
sandbox:
  provider: docker
  image: node:20-slim
  resources:
    cpu: 4
    memory: "8Gi"
    disk: "20Gi"
    timeout: "2h"
  network: bridge
  mounts:
    - source: ~/.npm
      target: /root/.npm
      readonly: false
  environment:
    NODE_ENV: development
    LOG_LEVEL: debug
  workdir: /workspace

Sandbox Providers

Full container isolationThe most secure option with complete process isolation:
sandbox:
  provider: docker
  image: node:20-alpine
  resources:
    cpu: 2
    memory: "4Gi"
Capabilities:
  • Full filesystem isolation
  • Network namespace isolation
  • Resource limit enforcement
  • Custom Docker images
Use slim/alpine images for faster startup and smaller footprint.

Resource Specification

Control compute resources allocated to the sandbox:
resources:
  cpu: 4          # CPU cores (0.1 to 64)
  memory: "8Gi"   # Memory (e.g., "512Mi", "4Gi")
  disk: "20Gi"    # Disk space (e.g., "10Gi")
  timeout: "2h"   # Execution timeout (e.g., "30m", "1h", "2h")
Format Reference:
ResourceFormatExamples
cpunumber0.5, 2, 4
memorystring"512Mi", "4Gi"
diskstring"1Gi", "20Gi"
timeoutstring"30m", "1h", "24h"

Network Modes

Control sandbox network access:
network: bridge  # or 'none' or 'host'
ModeDescriptionUse Case
noneNo network accessSecurity-sensitive tasks
bridgeIsolated network with internetMost development tasks
hostFull host network accessIntegration testing

Volume Mounts

Share directories between host and sandbox:
mounts:
  # Cache directories for faster builds
  - source: ~/.npm
    target: /root/.npm
    readonly: false

  # Shared credentials (read-only)
  - source: ~/.aws
    target: /root/.aws
    readonly: true

  # Project dependencies
  - source: ./node_modules
    target: /workspace/node_modules
    readonly: false

Environment Variables

Pass environment variables to the sandbox:
environment:
  NODE_ENV: development
  LOG_LEVEL: debug
  DATABASE_URL: ${DATABASE_URL}  # From host environment
  API_KEY: ${API_KEY}
Be careful with sensitive environment variables. Consider using secrets management instead of embedding them in TaskSpecs.

Complete Examples

Minimal Execution

execution:
  workspace:
    source: local
    path: /path/to/project
  agent:
    driver: claude-code-subscription

GitHub with Docker

execution:
  workspace:
    source: github
    owner: mycompany
    repo: backend-api
    ref: develop

  sandbox:
    provider: docker
    image: node:20
    resources:
      cpu: 2
      memory: "4Gi"
      timeout: "1h"
    network: bridge

  agent:
    driver: claude-code-subscription
    maxTokens: 200000
execution:
  workspace:
    source: github
    owner: mycompany
    repo: monorepo
    ref: feature/new-api
    fork: false

  sandbox:
    provider: docker
    image: custom-dev:latest
    resources:
      cpu: 4
      memory: "8Gi"
      disk: "50Gi"
      timeout: "4h"
    network: bridge
    mounts:
      - source: ~/.npm
        target: /root/.npm
        readonly: false
      - source: ~/.cache
        target: /root/.cache
        readonly: false
    environment:
      NODE_ENV: development
      LOG_LEVEL: debug
      CI: "true"
    workdir: /workspace

  agent:
    driver: claude-agent-sdk
    model: claude-opus-4-20250514
    maxTokens: 200000
    temperature: 0.7
    systemPrompt: |
      You are working on a large monorepo.
      Focus on the packages/ directory.
      Run tests before committing.
    tools:
      - name: bash
        enabled: true
      - name: file_system
        enabled: true
    capabilities:
      fileSystem: true
      network: true
      shell: true

Sandbox Lifecycle

1

Creation

AgentGate creates the sandbox based on provider configuration:
  • Docker: Pulls image and creates container
  • Subprocess: Prepares process environment
2

Workspace Setup

The workspace is cloned/mounted into the sandbox:
  • Git operations (clone, checkout)
  • Volume mounts applied
  • Environment variables set
3

Agent Execution

The agent runs within the sandbox:
  • Resource limits enforced
  • Network policies applied
  • Timeout monitoring active
4

Result Collection

Output is collected from the sandbox:
  • Stdout/stderr captured
  • Modified files tracked
  • Resource usage recorded
5

Cleanup

Sandbox is destroyed after execution:
  • Container removed (Docker)
  • Process terminated (subprocess)
  • Temporary files cleaned

Sandbox Registry

AgentGate tracks all active sandboxes for cleanup and monitoring:
interface SandboxInfo {
  provider: string;           // 'docker' | 'subprocess'
  containerId?: string;       // Docker container ID
  resourceUsage?: {
    cpuPercent: number;
    memoryMB: number;
  };
  durationMs: number;
}

Orphan Detection

AgentGate automatically detects and cleans up orphaned sandboxes:
  • Containers from crashed runs
  • Stale subprocess trees
  • Abandoned volume mounts

Best Practices

1

Choose the Right Workspace Type

  • local: Fast iteration on existing code
  • github: Full CI/CD integration
  • git: Non-GitHub repositories
  • fresh: Clean slate experiments
2

Size Resources Appropriately

Task TypeCPUMemoryTimeout
Simple fix1-22Gi30m
Feature2-44Gi1-2h
Large build4-88Gi2-4h
Monorepo4-816Gi4h+
3

Use Docker for Isolation

Always use Docker sandbox for:
  • Untrusted code
  • Production environments
  • Multi-tenant scenarios
4

Optimize with Mounts

Mount cache directories to speed up builds:
mounts:
  - source: ~/.npm
    target: /root/.npm
  - source: ~/.cache/pip
    target: /root/.cache/pip
5

Limit Network Access

Use network: none when possible:
  • Prevents data exfiltration
  • Ensures offline builds work
  • Reduces attack surface

Troubleshooting

Check image availability:
docker pull node:20-slim
Ensure Docker daemon is running:
docker info
Increase memory limit:
resources:
  memory: "8Gi"  # Increase from default
Or use a smaller base image:
image: node:20-alpine  # Smaller than node:20
For GitHub workspaces, ensure GITHUB_TOKEN is set.For git workspaces, configure credentials:
credentials:
  type: token
  token: ${GIT_TOKEN}
Increase timeout in resources:
resources:
  timeout: "4h"  # Increase from default 1h
Also check convergence limits:
convergence:
  limits:
    maxWallClock: "4h"
Check host directory permissions:
ls -la ~/.npm
chmod 755 ~/.npm
Or use readonly mount:
mounts:
  - source: ~/.npm
    target: /root/.npm
    readonly: true