Guide
Get binary and large artifacts out of the core
Pulling a big binary out of the core today — chunked base64 through `sh`. Token-expensive and fragile, but it works until `download.create_link` lands.
5/18/2026 · connect0 · 3 min
Getting large or binary results out of the core is still Connect — here's the survival path until the proper download surface ships.
You need a 4 MB PNG off the sandbox. sh "cat" won't survive the 64 KiB stdout cap, and even if it did, binary doesn't transport through MCP cleanly. Here's the workaround until the native download surface ships.
The shape
# Step 1: get the size.
sh "stat -c %s /workspace/diagram.png"
# → 4194304
# Step 2: chunk through base64.
sh "dd if=/workspace/diagram.png bs=40000 count=1 skip=0 status=none | base64 -w0"
sh "dd if=/workspace/diagram.png bs=40000 count=1 skip=1 status=none | base64 -w0"
sh "dd if=/workspace/diagram.png bs=40000 count=1 skip=2 status=none | base64 -w0"
# ... until you've covered the file.
Why 40000 bytes per chunk: base64 inflates by ~33%, so 40000 binary bytes → ~53400 base64 bytes, comfortably under the 64 KiB stdout cap.
Reassembling client-side
Concatenate the base64 strings in order, then decode:
# Pseudo: paste all the base64 chunks into chunks.b64
cat chunks.b64 | base64 -d > diagram.png
The agent can also do the reassembly for you if you're working in the conversation:
"Concatenate the base64 chunks you've shown me, decode, and tell me the SHA-256."
(It won't actually write a file on your machine — it just gives you a string you can paste into a printf '%s' '...' | base64 -d invocation.)
Why this is bad
- Tokens. Each base64 chunk goes through the LLM as text. A 4 MB file is ~100 chunks at the recommended size = a lot of context.
- Fragility. Drop one chunk, the binary is corrupt and silently so.
- Latency. ~100 round-trips through
shinstead of a singlecurlPUT. - Cost. You're paying for every byte twice (token in, token out per chunk).
When this is still the right call
- One-shot small binary the user really needs (a generated diagram, a single test artifact).
- Debugging where you want the human to inspect the file but don't have time to wait for the native download surface.
When you should not do this
- Anything > ~1 MB. Use a different egress path (GitHub push, S3 upload from the sandbox, etc.).
- Anything happening repeatedly. The token cost adds up fast.
- Anything where corruption isn't immediately visible (an encrypted blob, a database snapshot). You won't know it broke.
The proper fix: native downloads
The planned download surface mirrors the upload surface: a download.create_link MCP tool that returns a pre-signed GET URL, a browser-helper at /d/[token], a dashboard "Files" page. No tokens burned, no chunking, no manual reassembly. See the download preview.
Next steps
Where this fits
This is the Connect everything pillar of connect0 — the core that connects everything your company runs on. Even the awkward paths for getting bytes out are part of Connect — data leaving the core, deliberately. Start building → · All guides →