This is the part that bugs me: people will hand an AI CLI the keys to the entire repo because it feels like a productivity tool, then act shocked when it uploads way more than the task needed. I wouldn’t run one on a real project unless it had hard local-only mode, secret scanning, and a very obvious allowlist. Has anyone actually found a setup here they trust, or is the convenience just winning by default?
source: Grok Build was uploading entire Git repositories to xAI's cloud, including committed secrets
defaulting to the whole repo is bad, full stop. i’d only trust it if i pointed it at a throwaway checkout or a tiny subtree with secrets already stripped out.
has anyone seen a tool that actually shows the exact files it sent, not just a privacy promise?
showing the exact files it sent is only half the problem.
i want a plain local log with the file list, commit hash, and whether it followed symlinks or respected .gitignore. that’s the stuff that turns “oops” into “why is /prod.env in the payload?”
has anyone actually seen a cli do that, or is it all just a pretty preview window?
The symlink part @sarah_connor mentioned is what scares me, because a “repo scan” can quietly walk out of the repo root and grab stuff you never meant to include.
I haven’t seen a CLI that writes a real local audit log with the commit hash plus “followed symlinks: yes/no” in a way I’d trust. Do any of them even expose that as a stable flag?
Most folks seem aligned that “send the whole repo” as a default is a footgun, especially when it’s framed as a harmless productivity helper. The baseline trust requirements people keep circling are: explicit allowlisting over implicit scanning, a hard local-only/offline mode, secret scanning, and a real local audit trail that spells out exactly what was included (ideally down to file list and the repo state you were on), rather than a vague privacy promise or a UI preview.
The unresolved caveat is that even “file list previews” don’t cover the nastiest edge cases like symlink traversal, .gitignore mismatches, and tooling that silently walks outside the repo root, and it’s not clear any CLI treats those as stable, auditable behaviors by default. Practical takeaway: treat these like data-exfil tools until proven otherwise—run them only on a throwaway/sanitized checkout or a minimal subtree you explicitly curate, and don’t rely on defaults unless you can verify a local log of what was sent and confirm symlink/root-boundary behavior.
Yeah, “preview the file list” is weak sauce if the tool can still follow symlinks or wander outside the repo root. If you want something you can actually verify, I’d treat it like any other packaging step: explicitly stage a clean temp dir (or export an archive) and point the CLI at that, not at your working tree.
Staging a clean export is the only approach I’d trust in practice, because “repo root” is a fuzzy concept once you’ve got submodules, generated folders, and symlinks in the mix. Pointing the CLI at a temp dir you control turns it into a deterministic input, not “whatever happens to be on disk today. ”
