Claude Code reportedly hides a signal in requests: one apostrophe can mark your environment

Wed, 01 Jul 2026 21:15:26 +0800

Claude Code has recently been at the center of a controversy: according to reverse-engineering reports, some versions of Claude Code may read local environment information under certain conditions and encode the detection result into the system prompt sent to the server. The mechanism is not an obvious extra telemetry field. Instead, it modifies an ordinary-looking date line such as Today's date is 2026-06-30..

The most interesting part of the public discussion is not the account ban itself, but the detection flow. It shows how a local AI coding tool can carry client environment signals inside a normal request without adding an extra network call. For developers, that is more important than the account-risk angle alone.

This article summarizes technical details that repeatedly appear in public reverse-engineering posts and community discussion. Because this kind of analysis depends on concrete versions and reverse-engineering results, the following should be read as “the implementation logic reported publicly,” not as an official complete explanation.

First, the flow in plain language

In one sentence: it first checks whether you use a custom API address, then checks whether that address looks like a listed service, then checks your computer timezone, and finally hides the result in a date prompt.

According to public analysis, the rough chain is:

Before Claude Code starts or sends a request, it reads ANTHROPIC_BASE_URL.
If the variable does not exist, or still points to the official default address, the special marking logic may not trigger.
If it points to a custom endpoint, the client parses the URL and extracts the hostname.
The client compares the hostname with built-in domain lists and keyword rules.
It also reads the local timezone and checks whether it is a target timezone such as Asia/Shanghai or Asia/Urumqi.
The client does not add a separate field. It modifies the date sentence in the system prompt.
The server receives the request and reads the client-side environment mark from the date separator and the apostrophe code point.

The confusing part is step 6. It does not write an obvious field such as:

{
  "region": "CN",
  "proxyMatched": true
}

Instead, it puts the information into ordinary text:

`1`	`Today's date is 2026-06-30.`

Most people see only a date. The actual signal lives in whether the date uses / or -, and in the nearly identical apostrophe inside Today's.

In pseudocode, the logic looks roughly like this:

baseUrl = readEnv("ANTHROPIC_BASE_URL")

if baseUrl is empty or baseUrl is official api.anthropic.com:
    send normal system prompt
else:
    hostname = parseHostname(baseUrl)
    domainHit = matchDomainList(hostname)
    labHit = matchAiLabKeywords(hostname)
    timezoneHit = localTimezone in ["Asia/Shanghai", "Asia/Urumqi"]

    dateText = buildDateText()
    dateText = encodeTimezone(dateText, timezoneHit)
    dateText = encodeDomainStatus(dateText, domainHit, labHit)

    send system prompt with dateText

The point is not the exact function names, but the order: read local environment, make a local decision, then write the decision back into prompt text. The user sees an ordinary model request; the server sees a request carrying state.

What each step detects

Broken down further, each step does not collect something especially complex, but together they form a fairly clear environment profile.

Step	What the client reads	What it determines	Where the result is written
Read environment variable	`ANTHROPIC_BASE_URL`	Whether a custom API endpoint is used	Decides whether later logic runs
Parse URL	hostname	Which type of domain the endpoint belongs to	Affects the apostrophe code point
Match lists	Domain suffixes and keywords	Whether it hits specific services or AI lab keywords	Affects the apostrophe code point
Read system timezone	Local timezone	Whether it belongs to a target region	Affects the date separator
Rewrite prompt	Date sentence	Encodes previous decisions	system prompt

So it does not rely on a single signal. ANTHROPIC_BASE_URL is only the entry point. The hostname and timezone provide the later classification, and the system prompt carries the final result.

Trigger point: `ANTHROPIC_BASE_URL`

The first step mentioned in public analysis is reading the environment variable ANTHROPIC_BASE_URL.

This variable is commonly used to make Claude Code call a custom API endpoint, enterprise gateway, proxy service, or Anthropic-compatible relay instead of directly requesting the official api.anthropic.com. In other words, the variable itself is not malicious. Many teams use custom gateways for networking, compliance, auditing, unified authentication, or cost management.

According to public reverse-engineering analysis, the related logic does not trigger unconditionally for every request. It enters the later checks only after detecting a non-default API base URL. That design matters: it first separates ordinary official-direct users from users with custom endpoints, then performs more detailed environment identification on the latter group.

At a high level, the process can be divided into three layers:

Whether ANTHROPIC_BASE_URL is set.
Whether the URL’s hostname hits a specific domain or keyword list.
Whether the local timezone belongs to a specific region.

This is why the controversy focuses on local developer tools such as Claude Code. It runs on the user’s machine and can naturally read local environment variables, timezone, config files, and shell context.

Step one: extract the hostname from the custom endpoint

If ANTHROPIC_BASE_URL exists, the client can parse it as a URL and extract the hostname.

For example:

`1`	`https://example-gateway.com/v1`

The part that usually participates in matching is not the full URL, but:

`1`	`example-gateway.com`

This has two effects.

First, the path, query string, and API version do not matter. Only the domain body matters. Second, the matching logic can reuse one domain or keyword list without caring how each provider designs its API path.

Public discussion says this list is not stored as plain text in the code, but is obfuscated or encoded and decoded at runtime before matching. This does not necessarily prove malicious intent, but it does make the rules harder for ordinary users to discover by string search.

Step two: check the system timezone

Another repeatedly mentioned signal is the system timezone.

Public analysis says the logic pays attention to timezones such as:

1
2

Asia/Shanghai
Asia/Urumqi

Timezone is a subtle signal. It does not require a network request or an IP address, yet it can roughly reflect a user’s region or long-term system habits. Many developers may switch network routes, but they usually do not change the computer timezone, because doing so affects calendars, logs, build timestamps, and daily use.

If the client only looked at IP, a user might be behind a proxy, enterprise exit, or cloud environment. Looking at local timezone adds another local-environment layer.

Step three: match domain lists and keywords

In addition to timezone, public analysis also mentions two types of hostname matching:

Whether it hits specific domains, suffixes, or service-provider lists.
Whether it contains keywords related to AI labs, model services, or related companies.

The goal may not simply be deciding “is this a Chinese user.” It may classify different risk types: ordinary custom gateway, region-related endpoint, AI-lab-related endpoint, or multiple hits at once.

That also explains why the later encoding needs multiple states. If the only goal were “hit/not hit,” one binary mark would be enough. The Unicode character replacement described publicly can represent more combinations.

Key technique: write the result into the system prompt

The most controversial part is that the detection result is not uploaded as an explicit field, but encoded into a date sentence in the system prompt.

Claude Code requests already contain system information like:

`1`	`Today's date is 2026-06-30.`

Public analysis says the client modifies this sentence in two ways before sending the request.

The first is the date separator. If a target timezone is detected, the date may change from:

`1`	`2026-06-30`

to:

`1`	`2026/06/30`

The second is replacing the apostrophe in Today's. To the eye they are all apostrophes, but the Unicode code points differ. For example:

'
’
ʼ
ʹ

They look very similar when rendered, but they are entirely different characters to a program. The server only needs to check the code point between Today and s date is to recover the client-side state.

More intuitively, you can think of it as a “code table”:

Display	Unicode	Approximate meaning
`'`	`U+0027`	Normal ASCII apostrophe, no specific condition hit
`’`	`U+2019`	Hit a certain domain or suffix list
`ʼ`	`U+02BC`	Hit AI-lab-related keywords
`ʹ`	`U+02B9`	Multiple conditions hit at once

This table is not for bypassing detection. It explains why the mark is hard to spot by eye: all four characters look like apostrophes, but their code points are different. Logs, terminals, and web fonts can make the difference even less obvious.

This is why many people call it prompt steganography: hiding information inside text that appears normal.

Why this kind of mark is hidden

This approach is hidden for three main reasons.

First, it does not require an extra request. In a packet capture, you do not see a separate “upload environment information” endpoint. The request is still a normal model call.

Second, it does not require an obvious field. Even if you inspect the JSON, you may only see an ordinary system prompt. Unless you compare Unicode code points character by character, the apostrophe difference is easy to miss.

Third, it takes advantage of how little attention users pay to system prompts. Developers usually inspect their own prompt, tool-call parameters, token usage, and model output. They rarely check the client-generated system context character by character.

From an engineering perspective, this mechanism is clever. From a trust perspective, it is sensitive. Users grant Claude Code permission to run inside a local terminal so it can read and write code, execute commands, and assist development, not so local environment traits can be invisibly encoded into requests.

How the server can read this information

If the public analysis is correct, the server-side reading logic is simple.

It only needs to check two things after receiving the request:

Whether the date uses - or /.
Which Unicode character is used as the apostrophe in Today's.

In plain language: the client sends a “normal form,” but two tiny notes are tucked into the date format and apostrophe glyph.

For example, a normal request might look like:

`1`	`Today's date is 2026-06-30.`

After a target timezone is hit, it may become:

`1`	`Today's date is 2026/06/30.`

After a certain endpoint is hit, the apostrophe may become another Unicode character. To the eye it may still look like:

`1`	`Today’s date is 2026-06-30.`

But the program does not read the same '. The server does not need to understand the whole sentence. It only needs to extract characters at two positions to restore the mark state.

It can then classify the request into states such as:

no specific list hit
hit a certain domain list
hit AI-lab-related keywords
hit multiple conditions at once
system timezone belongs to a specific region

In other words, the real “reporting field” is not named region, proxy, or risk_flag. It is hidden in character differences inside natural-language system prompt text.

How this differs from ordinary risk control

It is not strange for a service provider to run risk control. API abuse, account resale, model distillation, abnormal concurrency, and regional policy violations are real problems. The issue is transparency and boundaries.

Ordinary risk control is easier to understand: login IP, payment region, request frequency, device information, organization account, API key usage pattern. These signals are also sensitive, but users can roughly expect platforms to use them for security decisions.

The controversy here is different: if the client really encodes local timezone and custom endpoint match results into the system prompt, users are unlikely to learn it from the product UI, request fields, or release notes. For a developer tool with filesystem and shell permissions, that directly affects trust.

What developers should pay attention to

The lesson is not simply “do not use a certain tool.” It is to re-examine the trust boundary of local agents.

Developers can watch for several things:

whether the local CLI reads environment variables, config files, timezone, system language, and similar environment data
whether the automatically assembled system prompt can be viewed, exported, and audited
whether the final payload can be inspected before the request is sent
whether release notes disclose new detection, risk-control, or telemetry logic
whether enterprise gateways can log and audit upstream request content
whether the local tool provides switches to disable telemetry or sensitive environment reads

If an AI coding tool can read and write project files, execute shell commands, access git, and read environment variables, it is essentially a high-privilege local agent. The transparency bar for such tools should be higher than for a normal chat webpage.

Conclusion

The real discussion in this Claude Code request-watermark controversy is not whether one account was banned, but how a client may encode environment information into a normal request.

According to public reverse-engineering analysis, the flow is roughly: read ANTHROPIC_BASE_URL, parse the hostname, match domain and keyword lists, check the system timezone, then write the result into the system prompt through the date separator and Unicode apostrophe. The whole process needs no extra network request and no new explicit field.

If this is part of anti-abuse risk control, the provider should still explain the boundaries more transparently. The more permission developers give a local agent, the more they need to know what it reads, what it rewrites, and what it sends.

As AI coding tools become more capable, trust cannot be solved by “just assume it is fine.”

Privacy Security on KnightLi Blog