Reports that a coding CLI transmitted unexpectedly broad local data are trending today. A social post is a lead, not a verdict, so the useful response is a reproducible audit.
Start with a disposable VM, a canary home directory, and a proxy you control. Put unique strings in ~/Documents/canary.txt
, .env.test
, Git configuration, and a fake SSH filename. Never use real secrets.
mkdir -p "$HOME/audit-home/Documents"
printf 'CANARY_DOC_7f31\n' > "$HOME/audit-home/Documents/canary.txt"
printf 'FAKE_TOKEN=CANARY_ENV_b921\n' > "$HOME/audit-home/.env.test"
Run the CLI with that directory as HOME
, deny access to the real home directory, and capture DNS, destination host, method, content type, byte count, and request timing. If TLS inspection is permitted in your environment, search decoded request bodies for the canaries. Otherwise compare encrypted byte volume while adding one fixture at a time.
Use four tests: empty prompt, prompt referencing one file, explicit repository upload, and a prompt-injection file asking the agent to read another directory. Record the exact CLI version, configuration, consent screen, and network policy.
The acceptance rule should be simple: every transmitted file must be attributable to an explicit user action or a documented minimal context rule. Block unknown destinations, require a preview for bulk transfer, and keep an append-only transfer manifest with paths hashed or redacted.
MonkeyCode is an open-source coding platform where this same boundary matters for workspaces and model backends. I contribute to the project; this is a tool-independent test plan, not a claim about MonkeyCode or the reported CLI incident.
Do not argue from packet size alone. Publish the fixture, version, capture method, observed destinations, and limitations so others can reproduce the result without exposing personal data.