China's AI Developers Pivot to Homegrown Tools After Claude Code Backdoor Alert
A government vulnerability database just named a specific AI coding agent as a security risk and told developers to uninstall it. That hasn't happened before — at least not at this scale, not from China's NVDB, and not against a tool as widely adopted as Claude Code.
On July 11, China's National Vulnerability Database (NVDB), overseen by the Ministry of Industry and Information Technology, published an alert claiming multiple versions of Anthropic's Claude Code contained a security "back door" capable of sending user locations and identities to remote servers without consent. The advisory told local organisations to uninstall the affected versions immediately or upgrade to patched releases. Cai Peng, a Beijing-based cybersecurity partner at Zhong Lun Law Firm, told the South China Morning Post he expected more Chinese companies to abandon foreign AI tools, driven by mounting security concerns and what he called the country's "strategic imperative" for tech self-reliance.
This is the moment to stop treating your AI coding toolchain as a productivity decision and start treating it as a part of your security perimeter.
What the NVDB actually flagged
A "back door" is a strong word, and it's used carefully. In vulnerability-disclosure language it usually means one of three things: a hidden network egress path the user didn't consent to, an undocumented account or credential, or an unauthenticated remote-access mechanism. The NVDB's wording — software that "could send user locations and identities to remote servers without consent" — maps cleanly onto the first definition. That's an architectural claim about the product, not a configuration mistake.
Two details separate this advisory from a routine CVE:
- It targets the tool, not a deployment. Most vulnerability reports name a specific version of a library with a patch path. The NVDB is naming a flagship AI coding product and telling users to remove it.
- It comes from a state-level database. When MIIT-overseen infrastructure publishes an advisory, the downstream effect on procurement, vendor approval, and corporate policy is structural. Compliance teams and purchasing decisions move within days, not weeks.
For developers inside China, the practical translation is straightforward: if your employer is a state-owned enterprise, a financial institution, or a company handling any data covered by the Cybersecurity Law or the Data Security Law, the Claude Code install is now a compliance question, not a productivity question. The patch path the NVDB offers ("upgrade to patched releases") is contingent on Anthropic shipping a version the agency considers clean, and on that version being reachable inside China's network.
Why this advisory is different from a normal CVE
The coding-agent category has been quietly exempted from most enterprise security reviews because it reads as "developer tooling" — productivity, not infrastructure. The NVDB just ended that exemption.
The interesting question is not whether Claude Code specifically is a back door. It's whether any AI coding agent that runs as a long-lived process on a developer's machine, with network access and access to source code, deserves the same scrutiny you'd give a database or a CI runner. Most teams have never run that audit. The Chinese developers who run it now will set a pattern that propagates.
One codebase. iOS, Android, and web.
The Fitness Kit ships with auth, a database, and a backend already connected — no setup. Live demo at fitness-preview.otf-kit.dev.
What the domestic alternatives are offering
The article doesn't name specific Chinese AI coding products, and I'm not going to invent any here. What it does name is the category of advantage Cai Peng expects to drive adoption. The shape is consistent across the domestic space:
- Data residency that stays inside mainland networks by default
- Model deployments that can be audited under China's algorithm registry
- Vendor accountability through entities MIIT can actually reach
- Pricing that undercuts dollar-denominated tools once FX and licensing terms are factored in
For a developer evaluating any candidate — domestic or otherwise — the practical audit is the same four steps:
# 1. Confirm the tool's data residency in writing
grep -iE "data residency|data location|境内|domestic" vendor-contract.pdf
# 2. Check whether the model is on the algorithm registry
# (ask the vendor for their 备案号 / filing number)
# 3. Capture egress — does the agent phone home at runtime?
sudo tcpdump -i any -w agent.pcap 'host <vendor-api-endpoint>'
# Inspect agent.pcap in Wireshark. Anything not in the contract is a finding.
# 4. Test in a sandbox with synthetic code first
git clone
# Run the agent against it. Watch what it sends.That last block — actually capturing the agent's network traffic during a normal coding session — is the audit step most teams skip. The NVDB's claim is fundamentally an egress claim. The only way to verify it against any tool is to watch the packets.
A fair comparison, with the gaps named
The article doesn't benchmark specific Chinese AI coding tools against Claude Code on speed or accuracy, so neither will I. A side-by-side on what's actually knowable looks roughly like this:
| Dimension | Claude Code (pre-patch) | Domestic Chinese AI coding tools |
|---|---|---|
| Regulatory posture in China | Subject of NVDB advisory | Aligned with MIIT and CAC registries |
| Data residency | Cross-border by default | Mainland-resident by default |
| Auditability of model | Foreign vendor, foreign jurisdiction | Domestic vendor, algorithm-registry filing |
| Procurement friction | Rising | Lower |
The honest gap: foreign tooling still has a meaningful lead in raw coding-agent capability on certain workloads, and that gap matters when the team is shipping product, not filing compliance reports. Cai Peng's point isn't that domestic tools are better today. It's that the security and sovereignty calculus is now bigger than the capability delta.
For teams that have to move regardless, the play is to start the migration on internal tools and non-customer-facing code, where a regression costs less. Customer-facing production code can wait until the new tool has earned trust on real workloads.
Migrating without breaking Friday
A clean migration is incremental and reversible. Treat it like a refactor, not a procurement event.
Days 1–3: Inventory. List every place the tool is installed: dev laptops, CI runners, internal portals, agent sandboxes. Capture the config so you know what you'll need to replicate in the replacement:
# Export your current agent config
<your-ai-tool> config list > ./pre-migration-config.txt
# Snapshot installed MCP servers, hooks, and slash commands
# (these are usually the things teams forget they depend on)Days 4–7: Pilot. One team, one non-customer-facing repo, one week. Run the new tool in shadow mode — it suggests, a human reviews and commits. Capture:
- Acceptance rate (suggestions kept / suggestions made)
- Latency p50 and p95
- Network egress volume and destinations
- Hallucinated APIs or invented package names
Days 8–14: Compare. Score the pilot against the baseline. If acceptance is below ~70%, the tool isn't ready for broader rollout. If egress goes anywhere unexpected, that's a security finding regardless of who signed the vendor contract.
Days 15–30: Roll out. Default the new tool for new code. Keep the old tool available for break-glass. Migrate existing code only when a human next touches it.
The mistake most teams make is treating this as a procurement decision instead of an engineering one. You're not buying software. You're changing how code gets written. The plan should look like a refactor plan: incremental, reversible, measured.
The durable layer underneath the churn
Here's the part that doesn't change when you swap Claude Code for a domestic alternative, or when Anthropic ships a patched release and the NVDB retracts the advisory: the components your users actually see.
A button is a button. A form is a form. Whether the agent that wrote them was trained in San Francisco or Shenzhen, whether it phones home or doesn't, whether it costs $20 a month or nothing — the rendered output on the user's screen has to look and behave the same on web, iOS, and Android. That's the layer below the model churn, and it's the only layer the team fully owns.

The AI coding tool you pick is a decision you'll revisit every 6–18 months. The component system underneath it is the thing you stop thinking about. Build that layer once, against an API your team controls, and the tool churn stops being a crisis every time a regulator — or a vendor — forces a swap.
Close
The NVDB advisory is the first state-level vulnerability notice aimed squarely at an AI coding agent. It won't be the last, in China or elsewhere. Cai Peng is right that the strategic imperative is real, but the practical imperative — auditing what your tools send and where — is one every team should be running regardless of which side of any border they sit on.
For Chinese developers and the companies that employ them, the shift is accelerating. For everyone else, the lesson is simpler: your AI toolchain is now a part of your security perimeter, and it deserves the same scrutiny you'd give a database or a deployment target.
When the model changes, the durable thing — the component, the API contract, the rendered output — is what carries the team through. Build that once, and the rest is just configuration.
Stop wiring. Start shipping.
- Login, database, and backend already connected — nothing to set up
- iOS + Android + web from one codebase
- AI configs pre-tuned + 40+ tested prompts included