A note to readers: there are no commercial incentives for us in the MiniMax Code release — but it came at a good time, given the harness telemetry issues that keep cropping up.
Imagine this: you are vibing hard on your coding project, and while you sleep and let the session sous-vide overnight, your harness uploads all that hard-vibed work to the cloud for unknown purposes. After reports of telemetry and git-snatching from Grok — and lest we forget Claude Code’s telemetry and watermarks — the latest culprit is ZCode.
Credit to ferstar for finding it: Inside ZCode: Silently Uploading Your Entire Git History to the Cloud.
First, what actually happened?
The developer noticed his storage was getting eaten up, and after a bit of searching (and to his dismay) came across an encrypted archive that was being uploaded somewhere. That archive was not a chat log. It was the workspace: the complete .git history, the LFS asset cache, logs, and global app configs, tarred, encrypted, and posted to Aliyun OSS. The key that wrapped the encryption came from the server at upload time and never touched the machine, so you cannot decrypt what was uploaded.
A snapshot of 42,411 files broke down like this:
| Content | Size | Proportion | What it carries |
|---|---|---|---|
.git/lfs/ |
196.1 MB | 56.8% | LFS cache: every binary asset and large media file ever downloaded |
.git/objects/ |
102.2 MB | 29.6% | The complete commit history object store |
.git/logs/ |
0.6 MB | 0.2% | Reflogs: local branch history and unpushed operational traces |
| Source code & docs | ~46.2 MB | 13.4% | src/, config files, internal documentation |
The .git directory alone is 86.6% of the payload, and that is the part worth sitting with. Uploading your working tree is one thing; uploading your lineage since the first commit is another, because history keeps what the tree deleted — API keys rotated out three commits later, unpushed branch names that spell out unreleased features, internal GitLab hostnames in .git/config.
At AIFinitee, we cross-checked independently, with other-source models and harnesses, on our own Windows machine. We found the telemetry, and we found the upload machinery: the same api/v1/snapshot/upload-credential endpoint, the same capture triggers, and a git-checkpoint channel that registers at startup — gated, as ferstar found in the code, on a valid login token rather than on any preference you can set. We did not reproduce an actual upload on our box, so treat the pipeline details as his and our check as confirmation that the machinery ships.
This isn’t great news for any user of this harness, but it makes the case for local, sovereign compute. The privacy policy — across the whole document, the FAQs, and the changelogs — describes collecting “text, files, and code submitted during conversations,” the normal thing you accept when you hand an agent your context. It never mentions packaging and uploading entire workspaces and full Git histories. And that is the uncomfortable part: this is not a case of fine print buried in the Terms & Conditions. It is not in the fine print at all.
With that, here is what to do. Note that the uploads only fire if you are logged in — if you are not, the snapshot pipeline should not trigger, though telemetry likely still is:
- Disable telemetry. Point your agent or harness (a non-ZCode one) at the checks below for reference points on the telemetry that is enabled.
- Switch to a fully open-source harness. Enter MiniMax Code.
Meanwhile: MiniMax Code went open source, and its telemetry is opt-in
The same week, MiniMax published the source for MiniMax Code — its terminal coding agent, headless CLI, and ACP implementation — imported on September 18, 2026 as a 0.4.12 source preview at MiniMax-AI/minimax-code. First-party code is MIT by default; third_party/sandbox-runtime stays Apache-2.0, and the bundled mcode-tools comes from a pinned public npm package.
OpenCode remains the popular choice, but for anyone looking to try something new, this one landed at a good time given the recent Grok and ZCode events. And because it is open source, you can validate its telemetry yourself. Here is what we found when we checked:
- Telemetry is off unless you turn it on. Their capability table states that usage, metrics, and diagnostics are “each disabled by default with separate opt-ins,” and
MCODE_DISABLE_TELEMETRY/DO_NOT_TRACKoverride all channels. - Error reports are off by default too, and require an explicit
telemetry.diagnosticsopt-in. - The workspace-snapshot machinery is gone from the open distribution. Their docs are blunt: runtime startup and conversation turns “do not collect workspace snapshots, create workspace ZIP archives, or upload/retry them for cloud indexing.”
- You can run it without an account at all. BYOK does not require a MiniMax login, so there is no JWT to gate a background pipeline.
That last point matters most for us: with no login requirement, you can point MiniMax Code at a model server on your own network.
What all this means to us
- Sovereign compute is not the default today — and yes, people don’t really want to pay for tokens — but dependency on cloud APIs and closed harnesses points users, over time, to the same gradual enshittification. The data gets harvested for training, and at scale that is immensely valuable to AI providers. In this case there are instances of forced uploading despite user consent — or buried somewhere in the fine print.
- Given the above, the more defensible way to engage is to reduce that dependency: auditable open-source harnesses, and open-source LLMs run locally.
- The RAMpocalypse is still ongoing, which means it is not the best time for (2) unless you have enthusiast or proper budgets. In the end, this may be less a consumer phenomenon and more of a business/on-prem trend.
That second half is no longer the compromise it was two years ago. Strix Halo remains the cheaper option. It is not the fastest, but it will run increasingly competent models — Qwen 3.8 Flash Next and DeepSeek V4 Flash among them — and that is a trade most of us are happy to make. Our own numbers:
| Setup | Prefill | Decode | Notes |
|---|---|---|---|
Single Strix Halo 128 GB, DeepSeek V4 Flash Q2 (ds4) |
~50–110 t/s | ~11–15 t/s | Our numbers, post 67; prompt processing slows as context grows |
| Two Strix Halos, TP=2 over RDMA | ~280 t/s | ~19–21 t/s | Our numbers; 23.15 Gb/s RDMA link |
So if you are looking for local compute with smarts, these are the options: start with our single Strix Halo DeepSeek V4 Flash Q2 guide, scale up to the two-node TP=2 build when you want the speed, and read Speed vs. Smarts for where a bigger cloud model still wins. The comparison that matters here is not capability. It is blast radius.
For agents and harnesses: disabling ZCode telemetry, and our own white-hat of telemetry and git uploads (written to be read by AI, not humans)
The natural first move is to find the setting and turn it off. Ferstar checked both candidates against the code:
| Switch | What you would expect | What it actually does |
|---|---|---|
Optimize Experience (optimizeAgentExperienceEnabled) |
Disables telemetry and data collection | Only controls whether data may be used for model training. Snapshot capture and upload keep running. |
Repo Snapshot Indexing (repoSnapshotIndexingEnabled) |
Disables the snapshot feature | Only controls whether the server indexes what it already received. Local packaging and upload continue. |
The capture sidecar is instantiated unconditionally at startup. There are no gating if checks against user preferences in that path; the only requirement is a valid JWT from the token provider. As long as you are logged in, the pipeline is live, and no UI setting turns it off. Capture fires at captureBeforePrompt before every prompt, and again on task completion tagged repo-wiki-update; one active session logged up to 62 capture events.
Check your own box before assuming either way:
# Look for captured archives and the state file that tracks them
ls -la ~/.zcode/v2/checkpoints/
du -sh ~/.zcode
On Windows, the same check in PowerShell:
Get-ChildItem "$env:USERPROFILE\.zcode\v2\checkpoints" -Force | Select-Object Name, Length
Get-ChildItem "$env:USERPROFILE\.zcode" -Recurse -Filter *.enc -ErrorAction SilentlyContinue
If you are staying: lock the directory
Deleting the archive is whack-a-mole: ferstar deleted his, and within half an hour the client had repacked it, retry counter ticking 564 to 565. The fix that holds is to deny write access at the filesystem level, so the packer fails before it produces anything to upload.
On macOS:
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
chflags uchg ~/.zcode/v2/checkpoints
touch ~/.zcode/v2/checkpoints/test # expect: Operation not permitted
On Linux:
rm -rf ~/.zcode/v2/checkpoints
mkdir -p ~/.zcode/v2/checkpoints
sudo chattr +i ~/.zcode/v2/checkpoints
touch ~/.zcode/v2/checkpoints/test # expect: Operation not permitted
Windows has no immutable flag, so the closest equivalent is a deny ACE on the folder. We tested this on a throwaway directory: creating a new file inside is refused with “Access is denied,” and removing the ACE restores access.
rmdir /s /q "%USERPROFILE%\.zcode\v2\checkpoints"
mkdir "%USERPROFILE%\.zcode\v2\checkpoints"
icacls "%USERPROFILE%\.zcode\v2\checkpoints" /deny "%USERNAME%:(W)"
echo test > "%USERPROFILE%\.zcode\v2\checkpoints\test"
That last line is the verify step — if it prints “Access is denied,” the lock is working. To undo it later:
icacls "%USERPROFILE%\.zcode\v2\checkpoints" /remove:d "%USERNAME%"
Two caveats, stated plainly: an owner account can rewrite its own ACL, so this is a speed bump rather than the kernel-enforced immutability chflags uchg gives you; and on our box that path is a file rather than a folder, so check what you actually have before locking it.
The trade-off: checkpoint rollback and the timeline UI stop working, since they always depended on uploading your code. Normal chat, autocomplete, and tool execution still work.
Over to you
If you run a coding agent against your repositories, spend five minutes on the checks above and tell us what you find in the comments — especially on Windows, where we could not reproduce the archive and would like more data points. And if you have already moved to an auditable harness, tell us which one, and why.
Looking for the local side of this? Start with our TP=2 RDMA recipe for what two Strix Halos can do together, and our DeepSeek V4 Flash Q2 guide for the single-box starting point.
