CodeWithRomi

Posted on Oct 12 Originally published at codewithromi.com

An AI Coding Agent Uploaded Whole Git Histories: How to Lock Down Your Homelab

#ai #security #docker #homelab

On 18 September 2026 a developer called ferstar published a teardown of ZCode, the desktop coding app from Z.ai (Zhipu AI) built on the GLM models, and the Hacker News thread that followed put it in front of everyone. While clearing disk space, ferstar noticed ~/.zcode holding more than 700 MB, unpacked the app, and found that a logged in client was packaging workspace snapshots and uploading them to Alibaba Cloud object storage. The snapshots were not just the source tree: in one 313 MB example covering 42,411 files, 86.6 percent of the payload was the .git directory, LFS objects and reflogs included. Each snapshot was encrypted with a key wrapped to a server held certificate, so the user could not decrypt their own upload. AI coding tools that run locally or integrate into your editor have deep filesystem access by design, and that access is increasingly being used in ways that are not obvious from the UI. If you run a homelab and use any AI agent that touches your code, this is your wake-up call.

The resolution first, because it changes how you should read the rest. Z.ai responded the same day, initially attributing the uploads to a wiki generation feature. It deleted the Alibaba Cloud bucket on 20 September and on 21 September published ZCode's source under Apache 2.0 at github.com/zai-org/ZCode, citing third party audits. ferstar's follow-up review of the published code found the upload endpoint, the object storage path and the key delivery code all absent from version 3.14.0 onward, with indexing running on locally bundled tools. So the specific behavior is gone. What nobody can audit is what happened to whatever was uploaded before 18 September, which is exactly why the cleanup below is still worth doing. Now: why homelabbers are a soft target, and what to do about it.

💡 Why This Matters for Homelabbers

Your homelab repos are not just toy projects. They often contain .env files, hardcoded API keys, internal IP ranges, VPN configs, Ansible inventories, and Docker Compose files with credentials baked in. Git history makes this worse because a secret you deleted three commits ago is still fully recoverable from the log.

AI coding agents are designed to read your project context, and that context is your entire repo tree. When an agent "understands your codebase," it is reading files and history. The question is whether it keeps that data local or phones home with it.

🧰 Prerequisites

A Linux or macOS machine running AI coding tools (ZCode, Cursor, the GitHub Copilot coding agent, Cline, Continue, etc.). If you see GitHub Copilot Workspace referenced in older guides, that preview was sunset on 30 May 2025 and its ideas moved into the Copilot coding agent.
Basic comfort with the terminal and Git
Optional: a network monitoring tool like mitmproxy, Wireshark, or a Pi-hole with logging enabled

🔍 Step 1: Audit What Your AI Tools Are Actually Sending

Before you lock anything down, you need to know what is leaving your machine. The bluntest tool here is watching outbound connections while your AI agent is active.

On Linux, use ss or nethogs to watch live traffic per process:

# Watch outbound connections from a specific process name
ss -tp | grep zcode

# Or monitor per-process bandwidth in real time
sudo nethogs

If you want to inspect the actual payload, route the tool's traffic through mitmproxy. Install it, set your HTTP_PROXY and HTTPS_PROXY environment variables to point at it, and trust its certificate. Then launch the AI agent from the same shell session and watch what it posts. Check the official docs for your specific tool to understand whether it respects proxy settings.

export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
# Then launch your agent in the same terminal

🔧 Step 2: Scrub Secrets from Git History Before They Can Be Harvested

If you have ever committed a secret to a repo that an AI agent can read, treat that secret as compromised. Rotate it first, then clean the history. The two most practical tools for this are git filter-repo and BFG Repo Cleaner. Check each project's documentation for the exact flags, since the syntax differs and getting it wrong can corrupt history.

A basic git filter-repo invocation to strip a file from all history looks like this:

# Install git-filter-repo first (see https://github.com/newren/git-filter-repo)
git filter-repo --path secrets.env --invert-paths

After rewriting history, force-push to all remotes and immediately rotate any exposed credentials. Do not skip the rotation step. Cleaning history only helps for future reads.

🛡️ Step 3: Use a .gitignore (and a Global One)

The fastest mitigation is making sure sensitive files never enter Git in the first place. Add a thorough .gitignore to every project and also configure a global gitignore that covers your whole machine.

# Set a global gitignore
git config --global core.excludesFile ~/.gitignore_global

# ~/.gitignore_global: common patterns to exclude
.env
.env.*
*.pem
*.key
id_rsa
id_ed25519
secrets/
vault_pass.txt
ansible/group_vars/all/vault.yml

This does not protect history that already exists, but it prevents new secrets from being committed accidentally, which is the most common source of leaks.

🛡️ Step 4: Sandbox AI Agents with Network Policies

If you want a harder boundary, run AI coding tools inside a sandboxed environment that limits outbound network access. There are a few practical ways to do this in a homelab.

Docker with network restrictions: Run the agent in a container with --network none or a custom bridge that only allows connections to your LAN and a specific AI API endpoint.
Firewall rules per user: On Linux, you can use iptables or nftables to restrict outbound traffic from a specific Unix user that you create just for running the agent.
A dedicated VLAN: If you have managed switches and a router that supports VLANs (like pfSense or OPNsense), put your dev machine on a VLAN where you can log and filter all outbound connections at the firewall level.

The VLAN approach is the most powerful because it works regardless of what the agent does inside your OS. You see everything at the network edge.

🛡️ Step 5: Prefer Local or Self-Hosted Models Where Possible

The cleanest solution to data exfiltration is keeping data on your own hardware. Tools like Ollama let you run capable open-source models locally and expose them on a local API endpoint. Many AI coding frontends (Continue, for example) can be pointed at a local Ollama instance instead of a cloud API.

# Example: point Continue or a compatible tool at a local Ollama endpoint
# In the tool's config, set the API base URL to:
http://localhost:11434

You give up some model capability compared to frontier cloud models, but for sensitive internal codebases the trade-off is often worth it. Check the documentation for whichever coding agent you use to confirm it supports custom API base URLs and what model format it expects.

🔧 Troubleshooting

mitmproxy shows no traffic from the agent: Some tools use certificate pinning or ignore system proxy settings. Try monitoring at the network level with Wireshark on your loopback or default interface instead.
git filter-repo says "not a git repository": Make sure you are running the command from inside the repo root, and that you have the tool installed correctly. It is not bundled with Git by default.
Ollama model responses are slow: This is normal on CPU-only hardware. Quantized models (Q4 or Q5) give you a better speed and quality balance on machines without a dedicated GPU. Check the Ollama model library for available quantization levels.

✅ Wrap Up

The ZCode incident is a reminder that AI coding agents are powerful precisely because they have broad access to your project context, and that access can be abused, intentionally or accidentally. ZCode itself was patched and opened up within days, so treat this as a warning about the category rather than about one product, and note what it took to find out: a paying user had to measure a directory, unpack an Electron bundle and watch the traffic. Your homelab repos deserve the same scrutiny you would give a production environment.

Start by auditing what your current tools are sending, scrub any secrets from Git history, and put network-level controls in place so you can see and limit outbound connections. If you are dealing with genuinely sensitive internal code, a local model via Ollama is worth the setup time. These are not exotic measures. They are just good hygiene for an era where your code editor is also a networked agent.

Related from the lab

Originally published at codewithromi.com.

DEV Community