# When Your AI Coding Tool Reads Your Code, Where Does It Actually Go > Source: > Published: 2026-07-10 07:53:10+00:00 Claude Code restricted access for users in China this week, and around the same time China's Ministry of Industry and Information Technology released a security bulletin calling out data transmission risks in AI coding tools. The two events landing in the same week dragged a question back into the open that's been easy to ignore while productivity gains kept rolling in: when AI coding tools read and process your code, where does that code actually go. AI coding assistants have moved well beyond autocomplete over the past year. Teams use them to write tests, do code review, parse logs, debug production issues, and even weigh in on architecture decisions. The efficiency gains aren't really debatable at this point. What's less discussed is the permissions model underneath all of this. When you grant a tool like Cursor, GitHub Copilot, or Claude Code access to your working directory, it doesn't just see the file you currently have open. It indexes the entire repository structure, parses configuration files, reads .git history, and builds a map of how your modules relate to each other — all of which is genuinely necessary for good code suggestions. The thing is, .env files with database credentials and API keys are in that directory too. So is deployment configuration. Most tools don't automatically exclude them unless you explicitly configure exclusions. Index data and code context get transmitted to cloud servers for processing. Cursor's privacy policy states this plainly; you can opt out of data collection but lose some functionality. Copilot sends context through GitHub and OpenAI's servers. Both vendors say they don't train on private code in their current terms. The transmission still happens. The access restrictions on Claude Code generated a stronger reaction than many people expected, and the reason has less to do with one specific tool being unavailable and more to do with how deep the dependency already runs. A lot of teams weren't just using it for autocomplete — code review, test generation, debugging, and architecture discussions were all happening inside the tool. When the service became inaccessible, entire workflows seized up. From what we've seen, a number of teams started evaluating alternatives immediately after the incident, ranging from domestic AI coding services to self-hosted open source models to fully local inference. Getting cut off once tends to rearrange priorities around vendor lock-in pretty quickly. For internet companies working on non-sensitive code, the tradeoff has generally been easy to make — productivity wins. Finance, government, manufacturing, and healthcare teams operate under different constraints. Cross-border data transfer, auditability, access control, and internal security compliance requirements often push data locality to the top of the priority list, above raw model capability. That's part of why local inference has been getting serious attention again. The historical knock on local models was performance — they were too slow, too small, not good enough for real work. That's been changing fast. We've seen this firsthand building Mano-P, our local GUI agent that runs on macOS. For GUI interaction tasks specifically, we trained a 4B parameter model called Mano-CUA-Thinking optimized for Apple Silicon using the MLX framework, paired with our own quantization SDK called Cider. There was real skepticism inside the team early on that a 4B model running locally could handle anything beyond demo-level tasks. On an M5 Pro, the model decodes at roughly 80 tokens/s with prefill under 3 seconds. In day-to-day use the latency is close enough to cloud APIs that you barely feel the difference. All screenshots, task descriptions, and inference happen on device — nothing gets uploaded to external servers. For teams working with internal systems, production environments, or any codebase with sensitive data, that property matters more than having the biggest model. On 100 real macOS GUI tasks, the local 4B model completed 56% successfully, compared to 39% for the cloud-based Qwen3-VL-Plus general-purpose vision-language model in the same test setup. A smaller specialized model outperforming a much larger generalist model on domain-specific tasks isn't a shocking result once you think about it, but it's the kind of thing that's hard to believe until you run the numbers yourself. Cider, our quantization SDK, handles INT8 inference on MLX. W8A8 prefill runs up to about 1.8x faster than W8A16 on M5 Pro. It started as an internal acceleration module for Mano-P and we ended up open-sourcing it separately once we realized how many people working on local inference were looking for exactly this kind of tooling. It's sitting at a little over 300 GitHub stars now, which was higher than we expected. None of this is to say local models are going to replace cloud services. Cloud models are still ahead on general programming tasks, cross-language coverage, and complex reasoning. They'll continue to be the right choice for open source work, learning, and anything non-sensitive. The change we're seeing is that for code that can't leave the building — core business logic, production configuration, internal systems — local inference is becoming a realistic option rather than a compromise. The broader shift here is that AI coding tools have stopped being toys and started being infrastructure. The conversation used to be about which model is smartest or fastest. Data sovereignty, auditability, and service availability are now just as much part of the evaluation. Model capability sets the ceiling on what's possible, but control over your code determines whether you can actually use it in production. Mano-P is open source under Apache 2.0. The 4B model weights, Cider SDK, and Mano-AFK autonomous builder are all available at github.com/Mininglamp-AI/Mano-P. On an M4+ Mac with 32GB RAM you can install with `brew install mano-cua` and run fully offline with the `--local` flag.