개념

현대적인 에이전트는 파일시스템의 실제 파일을 다룰 수 있을 때 가장 잘 작동합니다. 샌드박스 에이전트는 특화된 도구와 셸 명령을 활용해 대규모 문서 집합을 검색하고 조작하며, 파일을 편집하고, 아티팩트를 생성하고, 명령을 실행할 수 있습니다. 샌드박스는 모델에 지속적인 작업 공간을 제공하며, 에이전트는 이를 사용해 사용자를 대신해 작업할 수 있습니다. Agents SDK의 샌드박스 에이전트는 샌드박스 환경과 함께 에이전트를 실행할 수 있도록 도와주며, 파일시스템에 올바른 파일을 손쉽게 배치하고 샌드박스를 오케스트레이션해 대규모로 작업을 시작, 중지, 재개할 수 있게 합니다.

에이전트에 필요한 데이터를 중심으로 작업 공간을 정의합니다. GitHub 저장소, 로컬 파일 및 디렉터리, 합성 작업 파일, S3 또는 Azure Blob Storage 같은 원격 파일시스템, 그리고 사용자가 제공하는 기타 샌드박스 입력에서 시작할 수 있습니다.

SandboxAgent는 Agent를 확장하므로 여전히 Agent입니다. instructions, tools, handoffs, mcpServers, modelSettings, 출력 타입, 가드레일, 훅 같은 일반적인 에이전트 표면은 그대로 유지되며, 여전히 일반적인 run() 및 Runner API를 통해 실행됩니다. 달라지는 점은 실행 경계입니다.

SandboxAgent는 에이전트 자체를 정의합니다. 일반적인 에이전트 설정에 더해 defaultManifest, baseInstructions, runAs 같은 샌드박스 전용 기본값과 파일시스템 도구, 셸 접근, 스킬, 메모리, compaction 같은 기능을 포함합니다.
Manifest는 파일, 저장소, 마운트, 환경을 포함해 새 샌드박스 작업 공간의 원하는 초기 콘텐츠와 레이아웃을 선언합니다.
샌드박스 세션은 명령이 실행되고 파일이 변경되는 라이브 실행 환경입니다.
sandbox 실행 옵션은 이 실행이 해당 샌드박스 세션을 어떻게 얻을지 결정합니다. 예를 들어 세션을 직접 주입하거나, 직렬화된 샌드박스 세션 상태에서 재연결하거나, 샌드박스 클라이언트를 통해 새 샌드박스 세션을 생성할 수 있습니다.
저장된 샌드박스 상태와 스냅샷을 사용하면 이후 실행에서 이전 작업에 다시 연결하거나 저장된 콘텐츠로 새 샌드박스 세션을 시드할 수 있습니다.

Manifest는 새 샌드박스 작업 공간의 시작 콘텐츠를 정의합니다. 재사용된 세션, 직렬화된 세션 상태, 스냅샷은 모두 실행 시점에 작업 공간을 제공하거나 변경할 수 있으므로, 이것은 모든 라이브 샌드박스의 현재 파일을 설명하는 것은 아닙니다.

이 페이지 전체에서 “샌드박스 세션”은 샌드박스 클라이언트가 관리하는 라이브 실행 환경을 의미합니다. 정확한 경계는 클라이언트에 따라 달라집니다. Unix-local 세션은 호스트의 로컬 작업 공간에서 실행되는 반면, Docker 및 호스티드 클라이언트는 더 강한 환경 격리를 제공합니다. 이는 세션에서 설명하는 SDK의 대화형 Session 인터페이스와는 다릅니다.

바깥쪽 런타임은 여전히 승인, 트레이싱, 핸드오프, 재개 bookkeeping을 담당합니다. 샌드박스 세션은 명령, 파일 변경, 환경 격리를 담당합니다. 이 분리는 모델의 핵심 구성 요소입니다.

구성 요소 간 결합 방식

샌드박스 실행은 에이전트 정의와 실행별 샌드박스 설정을 결합합니다. 러너는 에이전트를 준비하고, 이를 라이브 샌드박스 세션에 바인딩하며, 이후 실행을 위해 상태를 저장할 수 있습니다.

SandboxAgent에이전트와 샌드박스 기본값

Runnerinstructions를 준비하고 기능 도구를 바인딩

샌드박스 세션명령이 실행되고 파일이 변경되는 작업 공간

저장된 상태나중에 재개하거나 새 작업 공간을 시드

샌드박스 전용 기본값은 SandboxAgent에 유지됩니다. 실행별 샌드박스 세션 선택은 sandbox 실행 옵션에 유지됩니다.

수명주기를 세 단계로 생각해 보세요.

SandboxAgent, Manifest, 기능을 사용해 에이전트와 시작 작업 공간 콘텐츠를 정의합니다.
샌드박스 세션을 주입, 재개 또는 생성하는 sandbox 실행 옵션을 run() 또는 Runner에 제공하여 실행을 수행합니다.
러너가 관리하는 RunState, 명시적 샌드박스 sessionState, 또는 저장된 작업 공간 스냅샷에서 나중에 이어서 진행합니다.

셸 접근이 간헐적으로 필요한 도구 하나일 뿐이라면 도구 가이드의 hosted shell부터 시작하세요. 작업 공간 격리, 샌드박스 클라이언트 선택, 또는 샌드박스 세션 재개 동작이 설계의 일부라면 샌드박스 에이전트를 사용하세요.

사용 시점

샌드박스 에이전트는 작업 공간 중심 워크플로에 적합합니다. 예를 들면 다음과 같습니다.

코딩 및 디버깅: GitHub 저장소의 이슈 리포트에 대한 자동 수정 작업을 오케스트레이션하고 대상 테스트를 실행
문서 처리 및 편집: 사용자의 금융 문서에서 정보를 추출하고 작성 완료된 세금 양식 초안을 생성
파일 기반 검토 또는 분석: 답변하기 전에 온보딩 패킷, 생성된 보고서, 아티팩트 번들을 확인
격리된 멀티 에이전트 패턴: 각 리뷰어 또는 코딩 하위 에이전트에 자체 작업 공간을 제공
다단계 작업 공간 작업: 한 실행에서 버그를 수정하고 나중에 회귀 테스트를 추가하거나, 스냅샷 또는 샌드박스 세션 상태에서 재개

파일이나 살아 있는 파일시스템에 접근할 필요가 없다면 계속 Agent를 사용하세요. 셸 접근이 간헐적인 기능 하나에 불과하다면 hosted shell을 추가하고, 작업 공간 경계 자체가 기능의 일부라면 샌드박스 에이전트를 사용하세요.

샌드박스 클라이언트 선택

로컬 개발은 UnixLocalSandboxClient부터 시작하세요. 컨테이너 격리나 이미지 parity가 필요하면 DockerSandboxClient로 이동하세요. 제공업체가 관리하는 실행이 필요하면 호스티드 제공업체로 이동하세요.

대부분의 경우 SandboxAgent 정의는 그대로 유지되고, sandbox 실행 옵션에서 샌드박스 클라이언트와 해당 옵션만 바뀝니다. 로컬, Docker, 호스티드, 원격 마운트 옵션은 샌드박스 클라이언트를 참고하세요.

핵심 구성 요소

레이어	주요 SDK 구성 요소	답하는 질문
에이전트 정의	`SandboxAgent`, `Manifest`, 기능	어떤 에이전트가 실행되며, 새 세션 작업 공간 계약은 무엇에서 시작해야 하나요?
샌드박스 실행	`sandbox` 실행 옵션, 샌드박스 클라이언트, 라이브 샌드박스 세션	이 실행은 어떻게 라이브 샌드박스 세션을 얻고, 작업은 어디에서 실행되나요?
저장된 샌드박스 상태	`RunState`의 샌드박스 payload, `sessionState`, 스냅샷	이 워크플로는 이전 샌드박스 작업에 어떻게 다시 연결하거나 저장된 콘텐츠에서 새 샌드박스 세션을 시드하나요?

주요 SDK 구성 요소는 다음과 같이 해당 레이어에 매핑됩니다.

구성 요소	담당하는 것	이렇게 질문해 보세요
`SandboxAgent`	에이전트 정의	이 에이전트는 무엇을 해야 하며, 어떤 기본값이 함께 전달되어야 하나요?
`Manifest`	새 세션 작업 공간의 파일과 폴더	실행이 시작될 때 파일시스템에 어떤 파일과 폴더가 있어야 하나요?
`Capability`	샌드박스 고유 동작	어떤 도구, instructions 조각, 또는 런타임 동작을 이 에이전트에 연결해야 하나요?
`sandbox` 실행 옵션	실행별 샌드박스 클라이언트 및 샌드박스 세션 소스	이 실행은 샌드박스 세션을 주입, 재개 또는 생성해야 하나요?
`RunState`	러너가 관리하는 저장된 샌드박스 상태	이전에 러너가 관리하던 워크플로를 재개하면서 해당 샌드박스 상태도 자동으로 이어가고 있나요?
`sandbox.sessionState`	명시적인 직렬화 샌드박스 세션 상태	`RunState` 밖에서 이미 직렬화한 샌드박스 상태에서 재개하고 싶나요?
`sandbox.snapshot`	새 샌드박스 세션용 저장된 작업 공간 콘텐츠	새 샌드박스 세션을 저장된 파일과 아티팩트에서 시작해야 하나요?

실용적인 설계 순서는 다음과 같습니다.

Manifest로 새 세션 작업 공간 계약을 정의합니다.
SandboxAgent로 에이전트를 정의합니다.
내장 또는 사용자 정의 기능을 추가합니다.
각 실행이 샌드박스 세션을 어떻게 얻어야 할지 run(agent, input, { sandbox: ... }) 또는 new Runner({ sandbox: ... })에서 결정합니다.

샌드박스 실행 준비 방식

실행 시점에 러너는 해당 정의를 구체적인 샌드박스 기반 실행으로 변환합니다.

sandbox 실행 옵션에서 샌드박스 세션을 확인합니다.
실행에 대한 유효 작업 공간 입력을 결정합니다.
기능이 결과 manifest를 처리하도록 합니다.
최종 instructions를 고정된 순서로 구성합니다. SDK의 기본 샌드박스 프롬프트 또는 명시적으로 재정의한 경우 baseInstructions, 그다음 instructions, 그다음 기능 instruction 조각, 그다음 원격 마운트 정책 텍스트, 마지막으로 렌더링된 파일시스템 트리입니다.
기능 도구를 라이브 샌드박스 세션에 바인딩하고, 준비된 에이전트를 일반적인 run() 및 Runner API를 통해 실행합니다.

샌드박싱은 턴의 의미를 바꾸지 않습니다. 턴은 여전히 단일 셸 명령이나 샌드박스 작업이 아니라 모델 단계입니다. 샌드박스 측 작업과 턴 사이에 고정된 1:1 매핑은 없습니다. 실용적인 규칙으로는, 샌드박스 작업이 발생한 뒤 에이전트 런타임에 또 다른 모델 응답이 필요할 때만 추가 턴이 소비됩니다.

`SandboxAgent` 옵션

다음은 일반적인 Agent 필드 위에 추가되는 샌드박스 전용 옵션입니다.

옵션	가장 적합한 사용 방식
`defaultManifest`	러너가 생성하는 새 샌드박스 세션의 기본 작업 공간
`instructions`	SDK 샌드박스 프롬프트 뒤에 추가되는 추가 역할, 워크플로, 성공 기준
`baseInstructions`	SDK 샌드박스 프롬프트를 대체하는 고급 escape hatch
`capabilities`	이 에이전트와 함께 전달되어야 하는 샌드박스 고유 도구 및 동작
`runAs`	셸 명령, 파일 읽기, 패치 같은 모델 대상 샌드박스 도구의 사용자 ID

샌드박스 클라이언트 선택, 샌드박스 세션 재사용, manifest 재정의, 스냅샷 선택은 에이전트가 아니라 sandbox 실행 옵션에 속합니다.

`defaultManifest`

defaultManifest는 러너가 이 에이전트용 새 샌드박스 세션을 생성할 때 사용하는 기본 Manifest입니다. 에이전트가 일반적으로 시작해야 하는 파일, 저장소, 보조 자료, 출력 디렉터리, 마운트에 사용하세요.

이것은 기본값일 뿐입니다. 실행은 sandbox.manifest로 이를 재정의할 수 있고, 재사용되거나 재개된 샌드박스 세션은 기존 작업 공간 상태를 유지합니다.

import { file, gitRepo, Manifest } from '@openai/agents/sandbox';

const manifest = new Manifest({
  root: '/workspace',
  entries: {
    'task.md': file({
      content: 'Fix the failing test and summarize the change.',
    }),
    repo: gitRepo({
      repo: 'openai/openai-agents-js',
      ref: 'main',
    }),
  },
  environment: {
    NODE_ENV: 'test',
  },
});

`instructions` 및 `baseInstructions`

서로 다른 프롬프트에서도 유지되어야 하는 짧은 규칙에는 instructions를 사용하세요. SandboxAgent에서 이 instructions는 SDK의 샌드박스 기본 프롬프트 뒤에 추가되므로, 내장 샌드박스 가이드를 유지하면서 자체 역할, 워크플로, 성공 기준을 더할 수 있습니다.

SDK 샌드박스 기본 프롬프트를 대체하고 싶을 때만 baseInstructions를 사용하세요. 대부분의 에이전트는 이를 설정할 필요가 없습니다.

넣을 위치	용도	예시
`instructions`	에이전트의 안정적인 역할, 워크플로 규칙, 성공 기준	”온보딩 문서를 검토한 뒤 핸드오프하세요.”, “최종 파일은 `output/`에 작성하세요.”
`baseInstructions`	SDK 샌드박스 기본 프롬프트를 완전히 대체	사용자 정의 저수준 샌드박스 래퍼 프롬프트
사용자 프롬프트	이번 실행의 일회성 요청	”이 작업 공간을 요약하세요.”
manifest의 작업 공간 파일	더 긴 작업 명세, 저장소 로컬 instructions, 또는 제한된 참고 자료	`repo/task.md`, 문서 번들, 샘플 패킷

사용자의 일회성 작업을 instructions에 복사하거나, manifest에 들어가야 할 긴 참고 자료를 포함하거나, 내장 기능이 이미 주입하는 도구 문서를 반복하거나, 모델이 실행 시점에 필요로 하지 않는 로컬 설치 메모를 섞는 것은 피하세요.

`capabilities`

기능은 SandboxAgent에 샌드박스 고유 동작을 연결합니다. 실행이 시작되기 전에 작업 공간을 조정하고, 샌드박스 전용 instructions를 추가하고, 라이브 샌드박스 세션에 바인딩되는 도구를 노출하고, 해당 에이전트의 모델 동작이나 입력 처리를 조정할 수 있습니다.

내장 기능은 다음과 같습니다.

기능	추가해야 하는 경우	참고
`shell()`	에이전트에 셸 접근이 필요할 때	`exec_command`를 추가하며, 샌드박스 클라이언트가 PTY 상호작용을 지원하면 `write_stdin`도 추가
`filesystem()`	에이전트가 파일을 편집하거나 로컬 이미지를 검사해야 할 때	`apply_patch`와 `view_image`를 추가하며, 패치 경로는 작업 공간 루트 기준 상대 경로
`skills()`	샌드박스에서 스킬 검색 및 materialization이 필요할 때	샌드박스 로컬 `SKILL.md` 스킬에 대해서는 `.agents`나 `.agents/skills`를 수동으로 마운트하는 대신 이것을 권장
`memory()`	후속 실행이 메모리 아티팩트를 읽거나 생성해야 할 때	`shell()`이 필요하며, 라이브 업데이트에는 `filesystem()`도 필요
`compaction()`	장기 실행 흐름에서 compaction 항목 이후 컨텍스트 트리밍이 필요할 때	모델 샘플링과 입력 처리를 조정

기본적으로 SandboxAgent.capabilities는 filesystem(), shell(), compaction()을 포함하는 Capabilities.default()를 사용합니다. capabilities: [...]를 전달하면 해당 목록이 기본값을 대체하므로, 원하는 기본 기능이 있다면 함께 포함해야 합니다.

개념

Manifest

Manifest는 새 샌드박스 세션의 작업 공간을 설명합니다. 작업 공간 root를 설정하고, 파일과 디렉터리를 선언하고, 로컬 파일을 복사해 넣고, Git 저장소를 clone하고, 원격 저장소 마운트를 연결하고, 환경 변수를 설정하고, 사용자나 그룹을 정의하고, 작업 공간 외부의 특정 절대 경로에 대한 접근을 허용할 수 있습니다.

Manifest 환경 값은 기본적으로 유지됩니다. 샌드박스 상태와 함께 저장되면 안 되는 API 키, 액세스 토큰, 기타 단기 자격 증명에는 { value: "...", ephemeral: true } 같은 ephemeral 항목을 사용하세요.

Manifest 항목 경로는 작업 공간 기준 상대 경로입니다. 절대 경로일 수 없고 ..를 사용해 작업 공간을 벗어날 수 없으므로, 작업 공간 계약을 로컬, Docker, 호스티드 클라이언트 전반에서 이식 가능하게 유지할 수 있습니다.

작업 시작 전에 에이전트에 필요한 자료에는 manifest 항목을 사용하세요.

Manifest 항목	용도
`file()`, `dir()`	작은 합성 입력, 보조 파일, 또는 출력 디렉터리
`localFile()`, `localDir()`	샌드박스 안으로 materialize되어야 하는 호스트 파일 또는 디렉터리
`gitRepo()`	작업 공간으로 가져와야 하는 저장소
`s3Mount()`, `gcsMount()`, `r2Mount()`, `azureBlobMount()`, `s3FilesMount()` 같은 mounts	샌드박스 내부에 나타나야 하는 외부 저장소

마운트 항목은 어떤 저장소를 노출할지 설명하고, 마운트 전략은 샌드박스 백엔드가 해당 저장소를 어떻게 연결할지 설명합니다. 마운트 옵션과 제공업체 지원은 샌드박스 클라이언트를 참고하세요.

권한

Permissions는 manifest 항목의 파일시스템 권한을 제어합니다. 이는 샌드박스가 materialize하는 파일에 관한 것이며, 모델 권한, 승인 정책, API 자격 증명에 관한 것은 아닙니다.

사용자는 작업을 실행할 수 있는 샌드박스 ID입니다. 해당 ID가 샌드박스에 존재하도록 하려면 사용자를 manifest에 추가한 뒤, 셸 명령, 파일 읽기, 패치 같은 모델 대상 샌드박스 도구가 그 사용자로 실행되어야 할 때 SandboxAgent.runAs를 설정하세요.

파일 수준 공유 규칙도 필요하다면 사용자와 manifest 그룹, 항목의 group 메타데이터를 함께 사용하세요. runAs 사용자는 누가 샌드박스 고유 작업을 실행하는지 제어하고, Permissions는 샌드박스가 작업 공간을 materialize한 뒤 해당 사용자가 어떤 파일을 읽고, 쓰고, 실행할 수 있는지 제어합니다.

SnapshotSpec

SnapshotSpec은 새 샌드박스 세션에 저장된 작업 공간 콘텐츠를 어디에서 복원하고 어디로 다시 저장할지 알려줍니다. 이는 샌드박스 작업 공간의 스냅샷 정책이며, sessionState는 특정 샌드박스 백엔드를 재개하기 위한 직렬화된 연결 상태입니다.

로컬의 영속 스냅샷에는 로컬 스냅샷을 사용하고, 앱이 원격 스냅샷 클라이언트를 제공하는 경우 원격 스냅샷을 사용하세요. 마운트된 경로와 ephemeral 경로는 영속 작업 공간 콘텐츠로 스냅샷에 복사되지 않습니다.

샌드박스 수명주기

수명주기 모드는 SDK 소유와 개발자 소유 두 가지입니다.

SDK 소유러너가 라이브 샌드박스를 소유합니다.

sandbox.client를 전달합니다.
러너가 샌드박스 세션을 생성하거나 재개합니다.
에이전트가 실행되고 스냅샷 기반 작업 공간 상태가 유지될 수 있습니다.
러너가 러너 소유 리소스를 닫습니다.

개발자 소유애플리케이션이 라이브 샌드박스를 소유합니다.

session을 생성합니다.
실행에 sandbox.session을 전달합니다.
에이전트가 기존 작업 공간을 사용합니다.
직접 검사하고, 재사용한 뒤, 세션을 닫습니다.

샌드박스가 한 번의 실행 동안만 살아 있으면 되는 경우 SDK 소유 수명주기를 사용하세요. client, 선택적 manifest, 선택적 snapshot, 클라이언트 options를 전달하면 러너가 샌드박스를 생성하거나 재개하고, 에이전트를 실행하고, 스냅샷 기반 작업 공간 상태를 유지하며, 클라이언트가 러너 소유 리소스를 정리하도록 합니다.

import { run } from '@openai/agents';
import { SandboxAgent } from '@openai/agents/sandbox';
import { UnixLocalSandboxClient } from '@openai/agents/sandbox/local';

const agent = new SandboxAgent({
  name: 'Workspace reviewer',
  model: 'gpt-5.5',
  instructions: 'Inspect the sandbox workspace before answering.',
});

const result = await run(agent, 'Inspect the workspace.', {
  sandbox: {
    client: new UnixLocalSandboxClient(),
  },
});

console.log(result.finalOutput);

샌드박스를 미리 생성하고 싶거나, 여러 실행에서 하나의 라이브 샌드박스를 재사용하고 싶거나, 실행 후 파일을 검사하고 싶거나, 직접 생성한 샌드박스 위에서 스트리밍하고 싶거나, 정리 시점을 정확히 제어하고 싶다면 개발자 소유 수명주기를 사용하세요. session을 전달하면 러너는 해당 라이브 샌드박스를 사용하지만, 이를 대신 닫아주지는 않습니다.

import { run } from '@openai/agents';
import { Manifest, SandboxAgent } from '@openai/agents/sandbox';
import { UnixLocalSandboxClient } from '@openai/agents/sandbox/local';

const manifest = new Manifest();
const agent = new SandboxAgent({
  name: 'Workspace reviewer',
  model: 'gpt-5.5',
  instructions: 'Inspect the sandbox workspace before answering.',
});

const client = new UnixLocalSandboxClient();
const session = await client.create({ manifest });

try {
  await run(agent, 'First task.', { sandbox: { session } });
  await run(agent, 'Follow-up task.', { sandbox: { session } });
} finally {
  await session.close?.();
}

`sandbox` 실행 옵션

sandbox 실행 옵션은 샌드박스 세션이 어디서 오는지, 그리고 새 세션을 어떻게 초기화할지를 결정하는 실행별 옵션을 담고 있습니다.

샌드박스 소스

다음 옵션은 러너가 샌드박스 세션을 재사용, 재개, 생성할지 결정합니다.

옵션	사용 시점	참고
`client`	러너가 샌드박스 세션을 생성, 재개, 정리하도록 하고 싶을 때	라이브 샌드박스 `session`을 제공하지 않는 한 필수
`session`	이미 직접 라이브 샌드박스 세션을 생성했을 때	호출자가 수명주기를 소유하며, 러너는 해당 라이브 샌드박스 세션을 재사용
`sessionState`	직렬화된 샌드박스 세션 상태는 있지만 라이브 샌드박스 세션 객체는 없을 때	`client`가 필요하며, 러너는 그 명시적 상태에서 소유 세션으로 재개

새 세션 입력

다음 옵션은 러너가 새 샌드박스 세션을 생성할 때만 중요합니다.

옵션	사용 시점	참고
`manifest`	일회성 새 세션 작업 공간 재정의를 원할 때	생략하면 `agent.defaultManifest`로 대체
`snapshot`	새 샌드박스 세션을 스냅샷에서 시드해야 할 때	재개와 유사한 흐름이나 원격 스냅샷 클라이언트에 유용
`options`	샌드박스 클라이언트에 생성 시점 옵션이 필요할 때	Docker 이미지, 제공업체 timeout 등 유사한 클라이언트별 설정에 흔함

concurrencyLimits는 샌드박스 materialization 작업이 병렬로 얼마나 실행될 수 있는지 제어합니다. 큰 manifest나 로컬 디렉터리 복사에서 더 엄격한 리소스 제어가 필요하면 manifestEntries와 localDirFiles를 사용하세요.

Materialization 제어

Materialization 제어는 의도적으로 실행별로 설정됩니다. 큰 로컬 디렉터리 복사에는 보수적인 제한을, 작은 manifest에는 느슨한 제한을 같은 SandboxAgent에 적용할 수 있도록 sandbox 실행 옵션 가까이에 두세요.

Manifest에 파일, 디렉터리, 저장소, 마운트 같은 독립 항목이 많다면 concurrencyLimits.manifestEntries를 사용하세요. localDir() 항목에 파일이 많아 로컬 복사 부담을 제한해야 한다면 concurrencyLimits.localDirFiles를 사용하세요.

전체 예제: 코딩 작업

이 코딩 스타일 예제는 기본 시작점으로 적합합니다.

import { run } from '@openai/agents';
import {
  Capabilities,
  Manifest,
  SandboxAgent,
  localDir,
  skills,
} from '@openai/agents/sandbox';
import {
  UnixLocalSandboxClient,
  localDirLazySkillSource,
} from '@openai/agents/sandbox/local';
import { dirname, join } from 'node:path';
import { fileURLToPath } from 'node:url';

const exampleDir = dirname(fileURLToPath(import.meta.url));
const hostRepoDir = join(exampleDir, 'repo');
const hostSkillsDir = join(exampleDir, 'skills');

const manifest = new Manifest({
  entries: {
    repo: localDir({ src: hostRepoDir }),
  },
});

const agent = new SandboxAgent({
  name: 'Sandbox engineer',
  model: 'gpt-5.5',
  instructions:
    'Read `repo/task.md` before editing files. Load the `$invoice-total-fixer` skill before changing code. Stay grounded in the repository, preserve existing behavior, and mention the exact verification command you ran. If you edit files with apply_patch, paths are relative to the sandbox workspace root.',
  defaultManifest: manifest,
  capabilities: [
    ...Capabilities.default(),
    skills({
      lazyFrom: localDirLazySkillSource(hostSkillsDir),
    }),
  ],
});

const result = await run(
  agent,
  'Open `repo/task.md`, fix the issue, run the targeted test, and summarize the change.',
  {
    sandbox: {
      client: new UnixLocalSandboxClient(),
    },
  },
);

console.log(result.finalOutput);

일반적인 패턴

위의 전체 예제에서 시작하세요. 많은 경우 동일한 SandboxAgent를 그대로 유지하면서 샌드박스 클라이언트, 샌드박스 세션 소스, 작업 공간 소스만 변경하면 됩니다.

샌드박스 클라이언트 전환

에이전트 정의는 그대로 두고 실행 설정만 변경하세요. 컨테이너 격리나 이미지 parity가 필요하면 Docker를 사용하고, 제공업체가 관리하는 실행이 필요하면 호스티드 제공업체를 사용하세요. 예제와 제공업체 옵션은 샌드박스 클라이언트를 참고하세요.

작업 공간 재정의

에이전트 정의는 그대로 두고 sandbox: { client, manifest }로 새 세션 manifest만 교체하세요. 동일한 에이전트 역할을 다른 저장소, 패킷, 작업 번들에 대해 에이전트를 다시 만들지 않고 실행해야 할 때 사용합니다.

샌드박스 세션 주입

명시적인 수명주기 제어, 실행 후 검사, 출력 복사가 필요할 때 라이브 샌드박스 세션을 주입하세요. 해당 실행에는 sandbox: { session }을 사용하고, 애플리케이션 코드에서 세션을 닫으세요.

세션 상태에서 재개

이미 RunState 밖에서 샌드박스 상태를 직렬화했다면 sandbox: { client, sessionState }로 러너가 해당 상태에서 다시 연결하도록 하세요. 샌드박스 상태가 자체 저장소나 작업 시스템에 있고 Runner가 그 상태에서 직접 재개하기를 원할 때 사용합니다.

스냅샷에서 시작

sandbox: { client, snapshot }으로 저장된 파일과 아티팩트에서 새 샌드박스를 시드하세요. 새 실행이 agent.defaultManifest만이 아니라 저장된 작업 공간 콘텐츠에서 시작해야 할 때 사용합니다.

Git에서 스킬 로드

로컬 스킬 소스를 skills({ from: gitRepo(...) })로 저장소 기반 소스로 바꾸세요. 스킬 번들에 자체 릴리스 주기가 있거나 여러 샌드박스에서 공유되어야 할 때 사용합니다.

도구로 노출

Tool-agent는 자체 샌드박스 경계를 가질 수도 있고, 부모 실행의 라이브 샌드박스를 재사용할 수도 있습니다. 재사용은 빠른 읽기 전용 탐색 에이전트에 유용합니다. 다른 샌드박스를 생성, hydrate, snapshot하는 비용 없이 부모가 사용하는 정확한 작업 공간을 검사할 수 있기 때문입니다.

대신 tool-agent에 실제 격리가 필요하다면 sandboxAgent.asTool(...)을 통해 자체 runConfig를 제공하세요. tool-agent가 자유롭게 변경해야 하거나, 신뢰할 수 없는 명령을 실행해야 하거나, 다른 백엔드나 이미지를 사용해야 한다면 별도의 샌드박스를 사용하세요.

로컬 도구 및 MCP와 결합

동일한 에이전트에서 일반적인 도구를 사용하면서 샌드박스 작업 공간도 유지할 수 있습니다. 샌드박스 기능은 tools, mcpServers, 핸드오프, 모델 설정, 출력 설정과 공존할 수 있습니다.

메모리

이후의 샌드박스 에이전트 실행이 이전 실행에서 학습해야 한다면 memory() 기능을 사용하세요. 메모리는 SDK의 대화형 Session 메모리와 별개입니다. 샌드박스 작업 공간 내부의 파일에 교훈을 추출해 저장하고, 이후 실행은 그 파일을 읽을 수 있습니다.

설정, 읽기/생성 동작, 멀티턴 대화, 레이아웃 격리는 에이전트 메모리를 참고하세요.

구성 패턴

단일 에이전트 패턴이 명확해지면, 다음 설계 질문은 더 큰 시스템에서 샌드박스 경계를 어디에 둘지입니다.

샌드박스 에이전트는 여전히 SDK의 다른 부분과 조합할 수 있습니다.

핸드오프: 샌드박스가 없는 intake 에이전트에서 문서 중심 작업을 샌드박스 리뷰어에게 넘기기
Agents as tools: 여러 샌드박스 에이전트를 도구로 노출하기. 보통 각 asTool(...) 호출에 샌드박스 실행 설정을 전달해 각 도구가 자체 샌드박스 경계를 갖도록 합니다.
모델 컨텍스트 프로토콜 (MCP) 및 일반 함수 도구: 샌드박스 기능은 mcpServers 및 일반 도구와 공존할 수 있습니다.
에이전트 실행: 샌드박스 실행도 여전히 일반적인 run() 및 Runner API를 사용합니다.

핸드오프에서는 여전히 하나의 최상위 실행과 하나의 최상위 턴 루프가 있습니다. 활성 에이전트는 바뀌지만 실행이 중첩되지는 않습니다.

asTool(...)에서는 관계가 다릅니다. 바깥 오케스트레이터는 도구 호출 여부를 결정하는 데 바깥쪽 턴 하나를 사용하고, 해당 도구 호출이 샌드박스 에이전트용 중첩 실행을 시작합니다. 중첩 실행은 자체 턴 루프, maxTurns, 승인, 그리고 보통 자체 샌드박스 실행 설정을 가집니다. 바깥 오케스트레이터 관점에서는 이 모든 작업이 여전히 하나의 도구 호출 뒤에 있으므로, 중첩된 턴은 바깥 실행의 턴 카운터를 증가시키지 않습니다.

추가 읽을거리

빠른 시작: 샌드박스 에이전트 하나를 실행해 보기
샌드박스 클라이언트: 로컬, Docker, 호스티드, 마운트 옵션 선택
에이전트 메모리: 이전 샌드박스 실행의 교훈 보존 및 재사용