In June 2026, a report filed in the public issue tracker for Claude Code, Anthropic’s terminal coding tool, described something that appeared in no release notes (claude-code issue #67120). Anthropic later described it as an experiment launched in March. It sat quietly for three months, and only surfaced because someone decided to read the code instead of trusting it. That is the recurring lesson of this beat, and it is why we keep doing the unglamorous work of reading source and watching sockets: the interesting behaviour is almost never in the documentation. For a business deciding which AI tools staff may install, the same habit is the approval process: check what the software sends before anyone signs it off.
What that report describes is the clearest example yet of a pattern we have been documenting tool by tool. AI software collects data its users cannot see, using methods its users were never told about, and the only reliable way to know is to check for yourself.
How the hidden tracker in Claude Code worked
The lists the code matched against were stored behind XOR and base64, so it did not read as tracking at a glance. What it did, once decoded, was specific. If a user had pointed the tool at a non-default server, it compared that server’s hostname against a concealed list of about 150 hostnames and a shorter list of keywords. Separately, it checked whether the system timezone was set to Asia/Shanghai or Asia/Urumqi.
When something matched, it did not write a normal log line. It hid the result inside the system prompt that travels with each request, using markers a person would never notice. The date format flipped from dashes to slashes. The apostrophe in a line like “Today’s date is” was swapped for one of several visually identical Unicode characters, each standing for a different flag. To a human reading the screen, and probably to the model itself, the text looked ordinary. To the server receiving it, it was a signal about who you might be.
The explanation came on 30 June 2026, when Thariq Shihipar, an engineer on the Claude Code team, acknowledged the code publicly as “an experiment we launched in March”. He said its purpose was to stop account abuse by unauthorised resellers and to protect against distillation, that stronger measures had since replaced it, and that the change removing it had been merged for the next day’s release. Anthropic gave CNBC the same account. Nothing about the code or its removal appears on Anthropic’s website, in its documentation or in the Claude Code changelog, and the issue itself drew no reply from the company and was closed as inactive in August. Alibaba banned Claude Code for its employees in early July and classified it as high-risk software. Days later China’s Ministry of Industry and Information Technology told users to uninstall or upgrade versions 2.1.91 to 2.1.196, released from April to June, and Anthropic, asked by CNBC, said the code was an experiment from earlier this year to protect against distillation.
Two things are worth keeping separate. The stated purpose is narrow: neither the issue report nor Anthropic’s reply says the code read your prompts or your files, only that it classified the server and timezone a user was working from, in the middle of a running fight between Anthropic and Chinese AI labs. And the method is a problem regardless of the purpose. The code was hidden, obfuscated, absent from the release notes, and it reported home in a way built specifically not to be noticed. It came out because a stranger found it, not because anyone disclosed it.
Why an AI company ships code it does not disclose
Almost none of this starts as villainy, which is exactly why it is worth understanding.
Most data collection in software has a mundane justification. Crash reporters catch bugs. Usage analytics tell a team which features are used. Fraud and abuse systems catch people reselling access or scraping a model to train a competitor. Anthropic’s stated reason, protecting against distillation, sits squarely in that last category, and it is a real problem for any company running an expensive model.
The trouble is that a reasonable motive produces an unreasonable design the moment three things are true: the collection is on by default, the user is not told plainly, and there is no working switch to turn it off. At that point it does not matter whether the intent was fraud prevention or surveillance, because the user has been removed from the decision. They cannot weigh the trade, because they were never shown it. Obfuscation and steganography push this further still: they are not the marks of a feature a company is proud of, they are the marks of one it expected to keep quiet.
What we found reading the tools ourselves
The Claude Code case is the loudest example, not the only one. We have found the same shape in tool after tool by installing them and reading what they actually do.
In our comparison of two local AI agents, one shipped PostHog analytics switched on by default, with a hardcoded project key and an off switch documented nowhere. The other opened a Sentry error-reporting connection at every launch, with a compiled-in address and, across dozens of configuration flags, no way we could find to disable it. Neither is as deliberate as a steganographic tracker. Both leave the user in the same position: sending data they did not choose to send, to a service they were never told about.
Then there is the counterexample, which matters just as much. When we read the full source of a fast-growing tool before installing it, and later ran it while watching every socket, we found no telemetry at all. Its code graph was built locally with no network calls, and the only connections it opened were to the model server we pointed it at. That is proof the quiet-by-default design is a choice, not a law of nature. A tool can be built to keep your data on your machine, and some are.
What should a business check for hidden tracking in AI tools before approving them?
A procurement form asks whether a vendor is secure. It rarely asks what the software sends home on its first launch, which is the question every case above turned on. The checks below are the ones we ran on the tools in this series, and one technical person can run them on a test machine before a tool reaches a staff laptop.
- Install the tool on a spare machine and list its network connections at rest and during one ordinary task. Any connection to an outside address other than the model provider you chose needs a name and a reason from the vendor.
- Search the installed files for analytics and error-reporting addresses, such as a PostHog project key or a Sentry DSN. That is how we found the crash reporter that OpenCode contacts before you type anything, and no setting we could find turned it off.
- Where the vendor documents an off switch, test it rather than trust it. We pointed OpenJarvis’s analytics host at a listener on our own machine and sent the same question twice: one request left with analytics on, and none left with it off.
- Put a marker word in a prompt and search the captured traffic for it. In the same OpenJarvis test the word never appeared, which is how we know its payload carried counters and no message content.
- Read the release notes and the privacy page against what you saw, and put any gap to the vendor in writing. Code that checks timezone, locale or hostname deserves a direct question.
- Repeat the check on every update. The Claude Code tracker shipped in releases from April to June, so an approval given before April would not have covered it.
Record the result against the version you tested, with the date. A tool that passes is cleared at that version, not for good. A tool whose off switch works can be approved with the switch set in the configuration you hand to staff. A tool that sends data with no switch at all, as OpenCode did in our test, leaves the business a narrower choice: accept that traffic, or block the address at the network edge and confirm the tool still works without it.
How to check whether an AI tool is tracking you
You do not need to be the person who decodes an XOR-obfuscated domain list, though it helps that such people exist. There is a shorter version anyone can run.
Prefer tools whose source you can read. The Claude Code tracker was caught because the JavaScript inside Claude Code’s release binary can still be read and decoded. A tool built to resist that kind of inspection would have hidden it far longer. Open and local tools are not automatically safe, but they are checkable, and checkable is the whole game.
Watch the network. Point the tool at a task and run a socket monitor while it works, the way we watched a tool talk only to a local model and nothing else. A tool that claims to be private and opens a connection to an analytics host has told on itself.
Read the release notes against the behaviour, and be suspicious of a gap. Code that keys off your timezone, your locale, or your hostname, and code wrapped in obfuscation, is worth a second look, because legitimate features rarely need to hide.
The Claude Code episode is not really a story about one company being caught. It is a story about the only mechanism that caught them: someone read the code. As more of daily life runs through AI tools, the question is not whether a company means well. It is whether you can see what its software does, and switch off the parts you did not agree to. Until disclosure is the norm rather than the exception, the honest position is the one that beat began with. Do not take a tool’s word for it. Check.
Not every alarming-looking component is doing anything. When we checked the crash reporters bundled with three local AI apps in every local AI app ships a crash reporter, the process with the frightening name held no connection and had no upload address configured.
