Docker Sandboxes sbx: Claude Code di MicroVM Cloud

Kalimat di pengumuman Docker yang membuat saya membaca dokumentasinya adalah yang paling pendek: sebuah move menangkap filesystem sandbox dan membuatnya kembali di sisi seberang. Satu perintah, dua arah. Siapa pun yang pernah menyerahkan sesi agent setengah jadi ke rekan kerja, atau kehilangan satu jam kerja karena laptop tidur, tahu kenapa itu menarik. Kalimat seperti ini juga biasanya menyembunyikan bagian yang paling menarik, yaitu semua hal yang tidak ikut terbawa.

Saya belum menjalankan cloud sandbox untuk tulisan ini, jadi tidak ada benchmark milik saya di dalamnya dan tidak ada klaim bahwa ia berjalan mulus di praktik. Yang Anda baca adalah pembacaan teliti atas pengumuman Docker tanggal 2026-09-24 dan dokumentasi sbx, semuanya dibaca ulang pada 2026-10-17: model isolasi, workflow lokal, semantik move, tabel harga, dan daftar tempat di mana dokumentasinya sendiri menyuruh Anda berhati-hati. Jika dua halaman Docker saling berbeda, saya sebutkan.

Apa sebenarnya sandbox sbx itu

Setiap sandbox adalah microVM dengan kernel sendiri, VM image sendiri, dan Docker daemon privat sendiri. Agent punya kendali penuh di dalamnya, termasuk sudo, dan bisa menginstal package, membangun image, serta menjalankan container. Halaman security menyatakan batasnya dengan lugas: VM mencegah agent menjangkau apa pun di host kecuali yang dibagikan secara eksplisit. Itu jaminan yang berbeda dari container, yang berbagi kernel host, dan karena itu Docker memosisikan produk ini sebagai jawaban atas pertanyaan apakah aman menjalankan agent tanpa pengawasan.

Credential mengikuti logika yang sama. Halaman arsitektur menjelaskan sebuah proxy di sisi host: semua TCP keluar melewatinya, HTTP dan HTTPS lewat forward proxy, dan agent hanya melihat nilai sentinel sebagai pengganti key asli. Setelah request keluar dari microVM, proxy menukar sentinel dengan credential asli. Poin yang ditekankan Docker di pengumuman cloud itu berguna: prompt injection tidak bisa mencuri secret yang tidak pernah dipegang agent. Varian cloud memakai model isolasi dan CLI yang sama; hanya mesin di bawahnya yang berbeda.

Setup lokal dalam lima perintah

Instalasi berbeda per platform dan berakhir sama. Halaman produk mencantumkan Homebrew di macOS, winget di Windows, dan script get.docker.com dengan SBX=1 di Linux. Sbx login pertama meminta Anda memilih global network policy, dan pilihan itu berlaku untuk semua sandbox yang ada maupun yang akan dibuat, jadi layak dipikirkan semenit, bukan dipilih sekadar refleks.

# macOS. Windows: winget install Docker.sbx
# Linux:   curl -fsSL https://get.docker.com | sudo SBX=1 sh
brew trust docker/tap && brew install docker/tap/sbx

sbx login            # first run asks for a GLOBAL network policy:
                     # Open / Balanced (recommended start) / Locked Down

cd ~/my-project
sbx run --name my-sandbox claude   # mounts ~/my-project read-write

sbx ls               # name, agent, status, ports, workspace, age
sbx policy ls        # rules in effect; remove wildcards you do not need
sbx policy allow network registry.npmjs.org

sbx stop my-sandbox  # state persists, resume later
sbx rm my-sandbox    # deletes the VM and everything inside; host files stay

Tiga policy-nya adalah Open, yang mengizinkan semua traffic, Balanced, yang menolak secara default tetapi mengizinkan layanan development umum dan menjadi titik awal yang direkomendasikan Docker, dan Locked Down, yang memblokir semuanya termasuk API model provider sampai Anda mengizinkannya. Menjalankan sbx run dari direktori proyek me-mount direktori itu secara read-write, sehingga hasil edit agent muncul di working tree Anda dan Anda me-review-nya sebagai Git diff biasa. Semua yang diinstal agent selain itu tetap di dalam microVM dan hilang ketika sandbox dihapus.

Trust boundary, dan apa yang bocor melaluinya

Lapisan isolasi di dokumentasi ada lima: kernel terpisah per sandbox, network proxy deny-by-default, Docker Engine privat tanpa jalur ke daemon host, mode workspace yang Anda pilih, dan credential yang disuntikkan proxy. Sandbox tidak bisa berkomunikasi langsung satu sama lain, ICMP selalu diblokir, dan UDP diblokir kecuali fitur eksperimental diaktifkan dan policy mengizinkan. Anggap itu fakta yang bisa Anda andalkan.

Halaman yang sama jujur soal apa yang tidak terlindungi, dan daftar itulah tempat saya akan menghabiskan waktu review. Pada mode direct mount, agent bisa mengubah file yang berjalan secara implisit di mesin Anda: Git hook di .git, yang tidak muncul di git diff, konfigurasi CI, task config IDE, target Makefile, dan script package.json. Aturan jaringan default memuat wildcard luas seperti subdomain googleapis.com, jadi channel yang diizinkan tetap bisa menjadi jalan keluar. Perintah instalasi kit berjalan sebagai root di dalam sandbox, dengan sumber kit dibatasi ke Docker Hub secara default.

Clone mode adalah mitigasi yang ditawarkan Docker untuk risiko workspace. Repository host di-mount read-only di /run/sandbox/source dan agent bekerja di clone privat di dalam VM, yang juga mode yang disarankan dokumentasi ketika beberapa agent berbagi satu repository.

Satu perintah ke cloud: sbx move

Bentuk yang didokumentasikan adalah sbx move local-project --to cloud, dan kebalikannya sbx move cloud-project --to local. Di bawahnya, move berjalan dalam tiga tahap: menangkap filesystem sumber sebagai template image, mentransfer image melewati batas, lalu membuat sandbox tujuan darinya dengan ID baru. Ini snapshot filesystem, bukan live migration. Proses yang berjalan, memori, dan socket terbuka tidak ikut, sumber tidak dihapus, dan tidak ada sinkronisasi setelah move.

# Before moving: credentials an agent wrote during sign-in are FILES,
# so they ride along in the snapshot. Remove them first.

# Local to cloud, with an explicit expiry. Without --ttl the server default
# (about one hour) applies, and a default action of delete loses the work.
sbx move local-project --to cloud --name cloud-project --ttl 4h --on-timeout stop

# Do NOT add the global --cloud flag to move; it already spans both backends.
# Managed secrets and network rules do not travel, so set them at the target:
sbx --cloud secret set anthropic
sbx --cloud create --name probe --allow-network github.com:443 claude   # policy example

# Verify both sides before deleting the source.
sbx ls
sbx --cloud ls
sbx --cloud ttl

# Cloud to local. Layer reuse can need up to 32 GiB of temporary disk.
sbx move cloud-project --to local --name local-copy

Flag-nya sedikit. Flag --name menetapkan prefix nama tujuan dan sisi cloud menambahkan suffix unik. Flag --ttl dan --on-timeout mengatur expiration untuk tujuan cloud, dengan on-timeout menerima stop, delete, atau restart. Flag --force melewati prompt konfirmasi tetapi tidak menyertakan file workspace dan tetap menampilkan peringatan soal pembatasan HTTP. Tidak ada flag CPU atau memori: limit yang tercatat dibulatkan ke atas ke ukuran cloud yang didukung, dan limit di atas ukuran terbesar memblokir move.

Untuk pekerjaan yang dimulai langsung di cloud, flag global --cloud mengganti backend: sbx --cloud ls menampilkan sandbox cloud, dan sandbox itu tidak muncul di sbx ls biasa. Cloud sandbox tidak menerima path workspace lokal, jadi Anda meng-clone repository di dalam sandbox dengan sbx --cloud exec, attach dengan sbx --cloud attach, detach dengan Ctrl+backslash agar agent tetap berjalan, dan ambil hasilnya dengan sbx --cloud cp.

Lokal versus cloud, baris demi baris

Halaman perbandingan Docker adalah halaman paling berguna di seluruh set, karena menyatakan bahwa lokal dan cloud adalah backend terpisah, bukan satu pool. Berikut baris-baris yang mengubah cara Anda bekerja.

CLI menegakkan pemisahan itu, bukan mengabaikannya: flag khusus lokal seperti clone mode, worktree --branch, --model, dan --provider ditolak jika digabung dengan --cloud. Cloud juga tidak punya filtering layer tujuh. Aturan HTTP method dan path tidak didukung, dan sbx move memberi peringatan lalu meminta konfirmasi jika sandbox lokal mengandalkannya.

Berapa biaya meternya

Compute diukur per detik dan tidak ada yang lain yang diukur. Sandbox yang di-pause tidak berbiaya, dan volume, egress, serta hosting image publik dan Kit gratis. Anda bisa membawa model key sendiri, sehingga inference tetap di provider yang Anda pakai. Pemakaian lokal gratis, termasuk untuk pekerjaan komersial. Ukuran dan tarif per jam di bawah berasal dari pengumuman Docker; kolom terakhir adalah hitungan saya, tarif satu jam dikali sepuluh.

Selusin agent pada ukuran Small default selama sepuluh jam masing-masing adalah dua belas kali 1,40 dolar, jadi 16,80 dolar compute, sebelum token model. Itulah aritmetika di balik tawaran Docker soal selusin agent berjalan lima, sepuluh, atau 21 jam masing-masing, dan murah dibanding token yang dibakar agent itu. Pengumuman menambahkan bahwa akun baru mendapat kredit Cloud Sandboxes gratis 250 dolar untuk waktu terbatas, cara yang bagus untuk menguji perilaku TTL di bawah tanpa biaya.

Kelayakan ditulis berbeda di dua halaman. Pengumuman menyebut paket pay-as-you-go tersedia di akun Docker Personal dan Pro dan tidak menyebut Team atau Business. Dokumentasi menyebut langganan Docker Agentic Platform yang aktif. Jika Anda di paket Team, cek halaman signup sebelum merencanakan sesuatu di atasnya.

Tempat ia patah: expiry, secret, dan nomor versi

Sisi paling tajam adalah masa hidup. Cloud sandbox kedaluwarsa setelah satu jam secara default dan berjalan sampai 24 jam per sesi. Saat kedaluwarsa, layanan men-stop sandbox yang bisa dilanjutkan dan menghapus sisanya, dan dokumentasi menyuruh Anda mengecek timeout action sebelum mengandalkan sandbox untuk menyimpan kerja Anda. Sandbox hasil move tanpa --ttl memakai default server, dan jika stop-on-expiration tidak tersedia, aksi default menghapusnya. Jadi angka 21 jam di pitch dan default satu jam sama-sama benar, dan jarak di antaranya adalah flag yang harus Anda atur. Pakai --ttl dan --on-timeout stop pada move, lalu konfirmasi dengan sbx --cloud ttl.

Sisi kedua adalah secret, dan berlaku dua arah. Managed secret tidak ikut pindah, jadi sandbox yang baru dipindah tidak punya model key sampai Anda menjalankan sbx --cloud secret set. Bahaya sebaliknya lebih senyap: credential yang ditulis agent ke file saat sign-in-nya sendiri adalah file, sehingga ikut masuk snapshot dan mendarat di cloud. Docker menyuruh Anda menghapusnya sebelum move.

Ketiga, jaringan. Aturan lokal tidak disalin, jadi hal pertama yang terjadi pada sandbox hasil move adalah berjalan di bawah policy cloud, yang harus Anda atur dan verifikasi sendiri. Keempat, workspace: sandbox lokal dengan workspace ter-mount berpindah tanpa file itu, dan CLI meminta konfirmasi. Pada pemakaian non-interaktif, move gagal kecuali Anda memberi --force, yang melewati prompt tetapi tetap meninggalkan file workspace dan tetap mencetak peringatan.

Dua catatan kecil. Dua halaman Docker berbeda soal versi minimum: pengumuman menyebut sbx 0.45.1 dan dokumentasi cloud menyebut 0.45.0, jadi instal yang lebih baru dan cek. Halaman get-started ditandai Early Access, dan laporan InfoQ mencatat bahwa klaim performa dan workflow datang dari pengumuman Docker tanpa pengujian independen. Komentator komunitas yang dikutip di sana berargumen bahwa sandbox hanya menutup sebagian risiko, karena agent yang bisa menjangkau package registry atau layanan internal tetap punya cara merusak.

Yang dikerjakan hari Senin

Mulai dari lokal dan gratis, dan perlakukan cloud sebagai langkah kedua yang baru Anda ambil ketika ada pekerjaan yang membutuhkannya. Urutan di bawah adalah urutan yang tersirat dari dokumentasi.

1. Instal sbx, jalankan sbx login, dan pilih Balanced kecuali ada alasan lain. Lalu jalankan sbx policy ls dan hapus aturan default yang tidak Anda perlukan.
2. Jalankan satu tugas nyata dalam clone mode, bukan direct mount, lalu periksa .git/hooks dan build script Anda sesudahnya.
3. Simpan model key dengan sbx secret set, dan beri akses GitHub dengan sbx secret set github --command 'gh auth token' hanya jika tugas membutuhkannya.
4. Sebelum memindahkan apa pun, hapus file credential dari sandbox, atur secret dan network policy tujuan, lalu move dengan --ttl dan --on-timeout stop.
5. Verifikasi tujuan dengan sbx --cloud ls dan sbx --cloud ttl, salin hasil keluar dengan sbx --cloud cp, dan baru kemudian hapus sumber dengan sbx rm.

# Cloud-native flow: no local workspace path exists, so clone inside the sandbox.
sbx --cloud diagnose
sbx --cloud secret set anthropic
sbx --cloud create --name nightly --allow-network github.com:443 claude
sbx --cloud exec nightly git clone \
    https://github.com/docker/welcome-to-docker.git /home/agent/workspace/project
sbx --cloud attach nightly            # detach with Ctrl+\, agent keeps running
sbx --cloud cp nightly:/home/agent/workspace/review.md ./review.md
sbx --cloud rm nightly                # deletes files stored only in the sandbox

# CI or headless: sign in with a Personal Access Token on stdin.
echo "$DOCKER_PAT" | sbx login --username your-docker-id --password-stdin

Untuk run tanpa pengawasan di CI, login dengan Docker Personal Access Token lewat standard input, seperti yang ditunjukkan dokumentasi cloud, dan simpan token di secret store CI, bukan di definisi job.

Klaim berguna dalam desain Docker bukanlah bahwa cloud lebih cepat; melainkan bahwa trust tidak boleh bergantung pada tempat agent berjalan. MicroVM, proxy yang memegang secret, dan policy yang Anda atur dengan sengaja adalah yang ikut terbawa, dan sisanya harus Anda bangun ulang di tujuan. Perlakukan sbx move sebagai salinan filesystem dengan checklist, beri setiap cloud sandbox expiry yang eksplisit, dan verifikasi sebelum menghapus sumber.