Run an agent that pushes its results to GitHub

An agent running on the core can push its own output straight from the isolated sandbox to GitHub.

connect0 doesn't ship a download surface yet (see the download preview). For code artifacts — generated source, tweaked configs, an agent's analysis output — pushing to GitHub from inside the sandbox is the cleanest workaround we have.

Prereqs

• The project has egress = open (GitHub is on the public internet).
• You have a GitHub Personal Access Token with repo scope, or a fine-grained token scoped to your target repo.

One-time setup

> Set up git in this project. Configure my name + email, and store this PAT for github.com pushes.

Agent runs:

sh "git config --global user.name 'Your Name'"
sh "git config --global user.email 'you@example.com'"
sh "git config --global credential.helper store"
sh "echo 'https://YOUR_PAT@github.com' > ~/.git-credentials"
sh "chmod 600 ~/.git-credentials"

Now any git call from the sandbox can push to GitHub without re-prompting for credentials.

The push flow

The agent has written /workspace/results/analysis.md and a generated /workspace/src/utils.ts. Push them to a repo:

sh "cd /workspace && git clone https://github.com/you/your-repo.git /workspace/repo"
sh "cp /workspace/results/analysis.md /workspace/repo/notes/"
sh "cp /workspace/src/utils.ts /workspace/repo/src/"
sh "cd /workspace/repo && git checkout -b agent/analysis-$(date +%s) && git add . && git commit -m 'agent: analysis run' && git push -u origin HEAD"

Open a PR from there, or just review the commit on GitHub.

Why this is the most reliable workaround

• GitHub is the destination most "developer" artifacts already belong in. Code, configs, scripts, generated docs.
• No size limits worth worrying about. GitHub accepts repos up to many GB.
• Diff-able. Once on GitHub, you have history, you have review surfaces, you can roll back.
• No connect0 tokens burned. The bytes flow sandbox → GitHub directly.

When this is the wrong tool

• The artifact isn't code-shaped. A 5 GB ML model doesn't belong in git. Use a different storage target (S3 with the bucket-owner's creds in the sandbox, Hugging Face's huggingface-cli upload, etc.).
• The artifact is private and you don't want it in a repo. Use aws s3 cp to your own bucket, or gsutil cp to GCS — same egress pattern.
• You need download UX for non-engineers. Wait for the native download surface; pushing to GitHub presumes the consumer knows git.

Security considerations

• The PAT is in the sandbox. Any future sh call against the same project can read ~/.git-credentials. If you'd rather not persist credentials, run a one-shot push:

  sh "GIT_ASKPASS=/bin/echo git push https://YOUR_PAT@github.com/you/repo.git HEAD"
  

• Fine-grained tokens preferred. Scope to the one repo, no broader org permissions.

• Rotate after a session. PATs in ~/.git-credentials survive across conversations. If a session ends and you don't need pushes anymore, sh "rm ~/.git-credentials".

Egress matters

If egress = restricted, git push fails — connection refused. Flip to open from the dashboard (/a/<account>/projects/<project> → Egress policy → save).

Next steps

• Today — get a file out of /workspace.
• For binary or large artifacts: the workaround.

Where this fits

This is the Run your agents pillar of connect0 — the core that connects everything your company runs on. The agent runs in an isolated sandbox on the core and ships its results out over git push — the bytes flow sandbox → GitHub directly, no round-trip through you. Start building → · All guides →