Get results out of the core

Getting results back out of the core is the same Connect story in reverse — here's the honest state of it today.

The honest version: there is no proper download path yet. Files written into /workspace by sh, by upload.write, or by an upload-link PUT all sit in R2 and can be read by the sandbox shell. Getting bytes back to the user's machine requires going through the shell, which has limits.

The only working path: sh "cat"

> Show me /workspace/result.json.

Agent:

sh "cat /workspace/result.json"

The stdout from that command flows back through MCP and into the conversation. The agent reads it; you read it via the agent.

The hard limit: 64 KiB per stream

sh caps each of stdout / stderr at 64 KiB. Anything larger comes back with truncated: true and the tail is gone. So:

• A small JSON report? Fine.
• A small Markdown doc? Fine.
• A 200 MB CSV? Useless — you'll see the first ~64 KiB and nothing else.
• A PNG? Useless — binary doesn't survive text-stream MCP transport anyway.

The workaround: base64 + chunking

For binary or larger files, the (uncomfortable) workaround is:

sh "base64 /workspace/diagram.png"

Token-expensive, fragile, and still capped at 64 KiB of base64 (= ~48 KiB binary). For anything that doesn't fit, you're chunking:

sh "dd if=/workspace/big.bin bs=40000 count=1 skip=0 | base64"
sh "dd if=/workspace/big.bin bs=40000 count=1 skip=1 | base64"
# ...

This is bad UX. It exists as a survival path, not as something we recommend.

What's coming: native downloads

A symmetric download.create_link tool that gives the agent a one-shot pre-signed GET URL the user opens in their browser. Plus a browser-helper at /d/[token] with a download button. Plus dashboard "Files" surface to browse the workspace.

Until that lands, the realistic posture is:

• Small text artifacts (JSON reports, summaries, generated docs): sh "cat" is fine.
• Anything bigger: either chunk it through base64 (painful) or land the result somewhere the user can pull it (a connected GitHub repo via sh "git push", an S3 bucket the user owns and the sandbox can write to with egress=open).

Should I just push to GitHub?

For code, yes — sh "git push" from inside the sandbox (with credentials the agent obtained via sh "git config") is a perfectly reasonable egress path that doesn't depend on connect0 shipping a download surface. For non-code artifacts, hold for the native download surface.

Next steps

• For binary or large artifacts: the workaround — the chunked-base64 details.
• What download.create_link will look like.

Where this fits

This is the Connect everything pillar of connect0 — the core that connects everything your company runs on. Pulling results out is the return leg of Connect — data leaving the core just as deliberately as it enters. Start building → · All guides →