Are you an LLM? View https://a3s-lab.github.io/Code/llms.txt for optimized Markdown documentation, or https://a3s-lab.github.io/Code/llms-full.txt for full documentation bundle. This page is also available as Markdown at https://a3s-lab.github.io/Code/en/guide/workspace-backends.md
Workspace backends decide where built-in workspace tools read and write files.
The default is the local filesystem rooted at the session workspace. All four
SDKs expose configuration for local files, S3-compatible object storage, and an
optional HTTP/JSON remote git provider. Go uses value configurations where
Node.js and Python use backend objects.
Use this surface when the host owns workspace placement: local development,
browser or container workspaces, object-storage workspaces, or managed sessions.
Rust hosts can also supply their own backend by implementing the workspace
traits; see Host-provided Backend.
The local backend and remote git are always compiled in. The S3 backend is
behind the Cargo feature s3, which the server and full features include
(core/Cargo.toml); the Core default feature set is local-code only.
Package
S3 in the published build
a3s-code-core (Rust)
Only when you enable s3, server, or full.
@a3s-lab/code (Node.js)
Yes; the published addon is built with advanced-harness,server.
a3s-code (Python)
Yes; the published wheel is built with server. Without it, S3WorkspaceBackend is not exported.
Go bridge (a3s-code-go-bridge)
No; the published bridge uses default features, so an S3 backend fails with FEATURE_DISABLED. Build the bridge with --features s3 (or server) to enable it.
download is registered only for a writable local root. code_symbols,
code_navigation, and code_diagnostics are registered only when the backend
carries a code-intelligence provider; the default local backend has none.
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.
A writable local backend also registers download. The tool accepts a public
HTTP(S) url and writes only to a workspace-relative file_path; omitting the
path produces a sanitized inferred filename. It is absent from S3 and other
non-local backends because atomic adjacent temporary files, cancellation
cleanup, symlink checks, and final promotion require local filesystem
semantics.
overwrite defaults to false. Transfers default to a 512 MiB max_bytes
limit and a 300-second timeout, with hard limits of 8 GiB and 3600 seconds.
Range concurrency is adaptive or explicitly bounded to 1–4 connections, and
expected_sha256 can require a 64-character hexadecimal digest before the
destination is promoted. See Tools
for transport and metadata details.
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.
Logical workspace root inside the bucket; use "" for the bucket root.
accessKeyId
access_key_id
yes
Access key id, normally read from the host environment.
secretAccessKey
secret_access_key
yes
Secret access key, normally read from the host environment or a secret manager.
endpoint
endpoint
no
Custom S3-compatible endpoint; omit for AWS S3 defaults.
region
region
no
Region, defaulting to us-east-1 when omitted.
sessionToken
session_token
no
STS session token when temporary credentials are used.
forcePathStyle
force_path_style
no
Set true for MinIO, RustFS, and most non-AWS endpoints.
maxReadBytes
max_read_bytes
no
Per-read size ceiling; defaults to 10 MiB.
searchEnabled
search_enabled
no
Enables degraded S3 grep / glob; defaults to false.
maxObjectsScanned
max_objects_scanned
no
Per-search object scan cap; defaults to 500. Used only when search is enabled.
maxGrepBytesPerObject
max_grep_bytes_per_object
no
Per-object grep download cap; defaults to 1 MiB. Used only with search.
searchConcurrency
search_concurrency
no
Concurrent grep object downloads; defaults to 8. Used only with search.
Go exposes the same fields on S3BackendConfig: Bucket, Prefix,
AccessKeyID, SecretAccessKey, Endpoint, Region, SessionToken,
ForcePathStyle, MaxReadBytes, SearchEnabled, MaxObjectsScanned,
MaxGrepBytesPerObject, and SearchConcurrency. Go additionally accepts
RequestTimeoutMS, a per-request S3 timeout that the Node.js and Python
backends do not expose.
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.
Remote git service base URL, without a trailing slash.
repoId
repo_id
yes
Opaque repository id negotiated with the remote git service.
bearerToken
bearer_token
production
Bearer credential for the remote git service; omit only in trusted development setups.
clientCertPem
client_cert_pem
no
mTLS client certificate path; must be paired with the client key.
clientKeyPem
client_key_pem
no
mTLS client key path; must be paired with the certificate.
requestTimeoutMs
request_timeout_ms
no
Per-call HTTP timeout in milliseconds; defaults to 30000.
maxDiffBytes
max_diff_bytes
no
Client-side cap on diff response bytes; defaults to 1 MiB.
maxLogEntries
max_log_entries
no
Client-side cap on log entries; defaults to 200.
Go exposes the same fields on RemoteGitBackendConfig: BaseURL, RepoID,
BearerToken, ClientCertPEM, ClientKeyPEM, RequestTimeoutMS,
MaxDiffBytes, and MaxLogEntries.
A Rust host can back a session with its own storage by implementing
WorkspaceFileSystem (read_text, write_text, list_dir) and, optionally,
WorkspaceCommandRunner, WorkspaceSearch, and WorkspaceGit. The traits are
Send + Sync and exported from the crate root. WorkspaceServices::builder
starts with read and write capabilities; each attached service enables the
matching capability and tools.
Attach .command_runner(...) for bash, .search(...) for search,
.git(...) for git, and .code_intelligence(...) for the code-intelligence
tools. A non-local backend keeps its own command runner: the native Bash
sandbox applies only to local workspaces, so the host is responsible for
confining commands it runs. Effect isolation never reuses a host-provided
backend. The Node.js, Python, and Go SDKs do not expose custom backends.