Workspace Backends
Workspace backends decide where built-in workspace tools read and write files. The default is the local filesystem rooted at the session workspace. The SDKs also expose typed backends for local files, S3-compatible object storage, and an optional HTTP/JSON remote git provider.
Use this surface when the host owns workspace placement: local development, browser or container workspaces, object-storage workspaces, or managed sessions.
Capability Matrix
Object storage cannot service local processes. Do not promise shell execution on an S3 workspace unless the host provides a separate sandbox through MCP or A3S Box.
Local Backend
The explicit local backend is useful when host code wants one option surface for both local and remote sessions.
S3 Backend
S3WorkspaceBackend points the built-in file tools at any S3-compatible service,
including AWS S3, MinIO, RustFS, Cloudflare R2, and Backblaze B2.
S3 search is intentionally opt-in. When enabled, grep / glob degrade to
object listing and bounded downloads. Configure maxObjectsScanned,
maxGrepBytesPerObject, and searchConcurrency when the bucket can be large or
the endpoint rate-limits.
S3 Options
Remote Git
remoteGit attaches an HTTP/JSON git provider on top of workspaceBackend. It is
designed for non-local workspaces where the built-in git tool cannot use a
local .git directory.
remoteGit requires workspaceBackend; passing it alone is rejected.
Keep remote git credentials out of agent.acl and agent directories. Inject them
from the host environment or secret manager.
Remote Git Options
Choosing A Backend
- Use the default local workspace for normal developer machines and CI checkouts.
- Use
LocalWorkspaceBackendwhen your host always passes a typed backend object. - Use
S3WorkspaceBackendwhen workspace state must live in object storage. - Add
remoteGitwhen a non-local workspace still needs the built-ingittool. - Use MCP or A3S Box for shell-like execution that cannot run inside the selected workspace backend.