This guide shows you how to read, write, and manage files inside a CoreWeave sandbox instance using the CWSandbox client. It’s intended for developers who build workflows that move data into and out of sandboxes, including parallel uploads and downloads, error handling, and patterns for large files.
Basic operations
The examples in this section cover the most common file operations: writing data to a path in the sandbox and reading data back. File operations return OperationRef objects. Use .result() to block for completion.
Write files
Read files
Parallel operations
File operations return immediately, enabling natural parallelism. Running uploads or downloads in parallel can reduce total transfer time when you have multiple independent files.
Parallel uploads
Parallel downloads
Upload-process-download pattern
A common workflow: upload input files, run processing, download results.
Error handling
File operations can fail if a path doesn’t exist or isn’t writable. Catch SandboxFileError to handle these cases and inspect the affected path.
File not found
Write errors
Binary files
File operations work with any binary content, including images and serialized Python objects:
Only unpickle data from sources you trust. Loading a pickle file can execute arbitrary code.
Text encoding
Files are transferred as bytes, so you must encode and decode text explicitly to avoid corruption with non-ASCII characters.
Large file considerations
The read_file and write_file APIs are best suited for small to moderately sized files. For large files, consider the following:
- Account for bandwidth, because files are transferred through the API.
- Use streaming for large datasets when possible.
- Access object storage directly instead of transferring the data through the API.
The object_storage_access parameter creates temporary CoreWeave AI Object Storage credentials and provides them to the sandbox’s containers. Your workload then reads and writes buckets directly, so large objects never pass through read_file or write_file. Your organization must first register a Workload Identity Federation configuration with the sandbox control plane; see Object storage access.
The following example starts a sandbox with read-write access to one bucket, then confirms the credentials were injected. Replace [BUCKET-NAME] with the name of your bucket:
The sandbox sets the environment variables that AWS SDKs read for container credentials, so any S3-compatible client inside it works without explicit keys. For those variables and a Boto3 example, see Use the credentials inside the sandbox.
To limit the credential to a key prefix, use object_prefix. For workloads that only read data, use ObjectStoragePermission.READ.
For large temporary data that stays local to the sandbox, attach a volume instead. See Volumes.