Someone reverse-engineered the Claude Code binary and found it quietly swapping a character in its system prompt—a Unicode apostrophe that is all but indistinguishable from the ordinary one—and, separately, replacing the hyphens in a date with slashes. Neither change is visible to a human reader. To a model, together they form a clear signal: what kind of environment a request came from, and whether it actually traveled the official path.
Researchers call the technique prompt steganography. But rather than being a "look, AI learned a new trick" moment, it's a good reason to stop and think. When a tool that can read your entire repository, run commands, modify files, and push commits starts embedding invisible attribution markers in its own outbound requests—what exactly is your trust in it built on?
What "steganography" means here
The word usually brings to mind information hidden inside images or audio. This case is a little different.
In the minified code of Claude Code (version 2.1.196), the researchers found a function that builds the date string in the system prompt sent to the model. Normally, that sentence looks like this:
Today's date is 2026-06-30.
But Claude Code has the ability to quietly alter two things:
- The apostrophe in
Today's - The date separator, changing
-to/
Whether and how it changes them depends on three things:
- The hostname that the
ANTHROPIC_BASE_URLenvironment variable (Claude Code's API base URL override) points to - The machine's system time zone
- Whether the hostname matches a list of domains and keywords tucked inside the binary
The apostrophe is the subtler part. Depending on what matches, the tool swaps the ordinary ' for one of several characters that look almost identical but are entirely distinct in Unicode:
' (plain ASCII)</td>
</tr>
<tr>
<td>Known domain</td>
<td>’ (U+2019)</td>
</tr>
<tr>
<td>AI vendor keyword</td>
<td>ʼ (U+02BC)</td>
</tr>
<tr>
<td>Both</td>
<td>ʹ (U+02B9)</td>
</tr>
</tbody>
</table>
In most monospaced fonts, these four characters are nearly impossible to tell apart. You see a normal English date; the model receives an encoded signal. The time zone part is more blunt: when the zone is Asia/Shanghai or Asia/Urumqi, the date renders as 2026/06/30 instead of 2026-06-30.
The researchers also found that the domain and keyword list used for the checks is stored in the binary obfuscated with base64 plus XOR (key 91). Decoded, the keywords include deepseek, moonshot, minimax, zhipu, baichuan, stepfun, 01ai, and others. The domain list is longer, covering enterprise domains of major Chinese companies as well as a large set of proxy, reseller, and gateway domains.
The marker travels with the request
The key issue isn't that a character gets changed—it's where the altered date string ends up.
The researchers point out that this date function is called while the agent's context is being built. In other words, the rewritten sentence becomes part of the system context and goes out with every request to the model. That invisible marker lands in the very prompt Anthropic's backend can see.
How the backend parses it or what it's used for—there's no official explanation. The researchers can only infer intent from code behavior; there's no evidence that the mechanism has been used for any specific purpose.
Why a vendor might mark requests
Seeing only "quietly changes characters" easily slides into "the vendor is watching users." But a calmer look shows a fairly practical set of needs behind the mechanism.
A coding tool like Claude Code is, by nature, a high-value, high-consumption entry point that is also easy to abuse. The vendor presumably wants to know a few things:
- Did this request come from the official Claude Code client?
- Has someone wired Claude Code into a non-official API gateway, proxy, or reselling service?
- Is someone running a "distillation" pipeline, feeding the official tool's output into their own model?
A custom ANTHROPIC_BASE_URL pointing at a known reseller's domain, or a hostname containing vendor keywords like deepseek or zhipu, is genuinely useful signal from a platform-governance perspective. The marking mechanism is most likely there to encode these signals into requests quietly, so the backend can do attribution.
So the question isn't entirely "should there be markers." It's "how should markers be done."
Why developers get uneasy
Understanding the vendor's needs doesn't mean developers shouldn't be uneasy. If anything, the particular nature of tools like Claude Code is exactly what makes invisible marking so sensitive.
A coding agent today has permissions that go far beyond an ordinary chatbot. It can read your code repository, run commands on your machine, install packages, modify files, and even push commits. Most developers accept that risk because the productivity gain justifies it.
And for precisely that reason, the client's own behavior should be the most boring, the most predictable, layer in the whole chain. When a tool with filesystem and shell access starts using invisible Unicode characters and obfuscated domain lists for internal attribution, developers react instinctively: if even a date string isn't what it appears to be, how much else in this tool is doing things I don't know about?
This wariness isn't anti-Anthropic. It's the natural cost of high-privilege tooling. The more capable a tool is, the more its trust has to be built on transparency.
Not prompt injection, not a supply chain attack
It's worth separating this from a few other risks developers already know well.
Prompt injection is an external attacker stuffing malicious instructions into your context, steering the model toward things it shouldn't do. A supply chain attack is cloning a poisoned repository or installing a malicious package, and having the tool get burned while executing. In both cases, the attacker is outside the tool.
The steganographic markers are different. They aren't an attack; they're a governance layer inside the tool itself—the vendor adding some internal attribution and audit capability to requests in its own client. It doesn't tamper with your code, it doesn't steer the model toward anything harmful, but it does change the content of outbound requests without your knowledge.
Getting this boundary straight matters. Worrying about prompt injection and supply chains is worrying that someone outside is out to get you. Worrying about steganographic markers is worrying about how transparent the tool you use every day actually is to you. They are problems on different axes, and one framework can't judge both.
A few boundary questions worth pressing
The researchers themselves say the mechanism is probably not malicious, but for a developer tool that asks for trust, the implementation is genuinely odd. Rather than chasing conspiracy theories, it's more useful to lay out the boundary questions.
First, is it disclosed? A mechanism that can encode attribution signals into requests should, in principle, appear in documentation or release notes—not hide behind a list of XOR-obfuscated domain names. Obfuscation isn't the same as malice, but it does raise the cost of discovery, and it weakens the default expectation that client behavior is auditable.
Second, can it be turned off? If the markers exist purely for platform anti-abuse, then for most users on official channels with normal time zones, they'll never fire anyway. But what about teams with legitimate reasons to use custom gateways, local proxies, or internal routing—enterprise compliance requirements, research environments, model routing? Can they turn it off, or at least be told it has been triggered? As far as anyone can tell, there is no such switch.
Third, does it reach into API behavior? The markers go into the system prompt—the layer the model can see. Could they affect model behavior, billing, or trigger a different service policy if some "suspicion marker" fires? None of this has been disclosed. The researchers are measured in their wording, saying only that Anthropic may parse it on the backend, without claiming more.
Fourth, does it actually work against real abusers? The researchers point out an awkward fact: the mechanism is trivially cheap to bypass. Change a hostname, change a time zone, patch the binary, wrap the process in a layer—the signal fails. What that means is that the people it actually catches are the ordinary developers doing something legitimate but non-standard, the ones most likely to leave fingerprints. Serious abusers wiped theirs long ago.
A closing note
What Claude Code has here isn't so much a scandal as a problem that was bound to surface as AI tools reached this stage.
When a coding agent shifts from "an assistant that completes code" to "a high-privilege workbench that reads repositories, executes, and ships," the relationship between vendor and user stops being simply "you use my model." Vendors need attribution, anti-abuse, and a way to spot unofficial channels; users need transparency, predictability, and a clear picture of what the tool on their machine is actually doing. Both sets of needs are legitimate. The question is where they meet and where they collide.
The researchers' attitude is remarkably calm: developer tools can enforce terms, API providers can detect abuse, companies can protect their models—none of that is objectionable. But when a tool with filesystem and shell access starts hiding attribution markers in invisible prompt punctuation, the right response is scrutiny, not default trust.
Trust is earned in the most boring places. That holds for Claude Code, and for every high-privilege AI tool that comes after it.