It depends on the tool. A cloud agent may clone from your git host, or bundle and upload your local repository, including history across branches and uncommitted edits to tracked files. Some tools skip files that look like credentials, but not on every platform. Read the documentation and test with a dummy secret first.
Two common paths
Clone from the host. The cloud environment pulls your repository from your git host, usually at the branch you name. Local commits you have not pushed are not included, and neither are local edits.
Upload from your machine. One platform documents that when a repository has no remote, or the host app is not installed on it, the tool bundles your local repository and uploads it. A full clone's bundle includes history across all branches plus uncommitted changes to tracked files. Documented limits include a size cap, after which it falls back to the current branch and then to a snapshot of the working tree. Untracked files are not included.
Sensitive files
The same documentation says that on macOS, Linux, and WSL, uncommitted changes to files named like credentials or keys are left out, including env files, Terraform variable files, and key files such as id_rsa and pem files, and it prints a notice naming what was left out. On native Windows, uncommitted changes to tracked files upload as they are, whatever the name. A rule based on file names is a helpful safety net, not a guarantee, so do not rely on it for secrets stored under other names.
What can be inside "the repository"
| Content | Why it matters |
|---|---|
| Full git history | Old commits may hold removed secrets |
| All branches | Includes unreleased work |
| Tracked config files | May contain tokens or internal hostnames |
| Vendored code and data | Customer data in fixtures |
| Submodule or LFS pointers | May expose paths or require extra credentials |
History is the one people forget. A secret deleted from the latest commit is still in earlier ones, and a bundle that includes history includes them.
Before you send a repository
- Decide whether the repository may leave your network at all.
- Prefer cloning from your host over uploading a local bundle, so you control what is committed.
- Check history for secrets and rotate any you find, whether or not you use the agent.
- Stash or commit local edits you do not want sent.
- Run a test with a dummy credential in an uncommitted file and see whether it is uploaded.
- Confirm what the platform retains, and for how long, and who can see session transcripts.
Why this connects to sandbox design
Whatever lands in the sandbox is readable by the agent, and by any prompt injection that steers it. Reduce what you send, narrow the network, and give the agent only the credentials it needs.
Worked example: a pre-flight check before the first upload
An illustrative checklist applied to a repository called orders-service.
- Classify the repository. It holds business logic and no regulated data. Allowed for cloud agents by policy.
- Check history for secrets. A history review finds an old committed test key, deleted two years ago. The key is rotated, regardless of whether the agent will be used.
- List branches. Three long lived feature branches contain unreleased work. The team decides to avoid bundle uploads and use host cloning of one branch.
- Check tracked config. A config file lists an internal hostname and a staging password. The password is moved to a secrets store and the file now reads from environment at run time.
- Test with a dummy. A fake credential is placed in an uncommitted env file. The team starts a task and confirms from the tool's notice that it was left out, and from the session that it was not present.
- Confirm retention. The team records the vendor's retention terms and who can view transcripts.
The team now knows what leaves and has fixed two real problems that existed before any agent arrived.
What each path sends
| Content | Host clone | Local bundle |
|---|---|---|
| Committed files on the chosen branch | Yes | Yes |
| Other branches | Not by default | Yes, for a full bundle |
| Full history | Depends on clone depth | Yes |
| Uncommitted edits to tracked files | No | Yes, with exceptions for sensitive names on some platforms |
| Untracked files | No | No |
| Local git config | No | Parts may be checked or refused |
Verify against your tool's current documentation, since details change.
Reducing what goes out
- Use a fresh clone of one branch for agent tasks.
- Remove vendored data and fixtures that contain real records, replacing them with synthetic data.
- Split sensitive modules into repositories the agent never sees.
- Keep large binary assets out of the repository the agent uses.
- Clean history only after rotating anything found. Rewriting history does not undo prior exposure.
Size and fallback behavior
One documented bundle path has a size limit, after which it falls back to a single branch and then to a snapshot of the working tree. That fallback changes what is sent without much fanfare, so read the notice the tool prints.
Record the decision
Write a short note: repository, path used, what was reviewed, what was fixed, who approved. It takes ten minutes and saves hours when someone later asks what the agent could see.
Where Safeguard fits
Safeguard provides dependency scanning, SBOMs, and policy gates, and you can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through it and look at what a project inventory lists, which is a good starting point for deciding what you are comfortable sending out.
Quick check
Does an ignore file keep secrets out of an upload?
Not necessarily. Check what your tool honors. Remove secrets from the repository and history instead.
Is pushing first safer than uploading?
It gives you a clear boundary: only committed, pushed content is cloned. Review what you commit.
Does rewriting git history fix a past exposure?
No. Rotate the credential first. History rewriting limits future copies but cannot recall copies already made.
Sources
- Use Claude Code in the cloud (Anthropic documentation)
- Configure cloud environments (Anthropic documentation)
Last reviewed: 19 October 2026.
