The Fight Is Not Really About One Marker
On June 30, 2026, a reverse-engineering post claimed that Claude Code 2.1.196 could alter the date string in its system context when a custom API base URL was configured, using nearly invisible punctuation and date separator changes as request markers. On July 1, Golem also covered the report, describing the behavior as barely visible prompt marking. That is the fact pattern being argued about, not a settled courtroom finding and not a reason to declare every coding assistant malware before lunch.
The more useful lesson is simpler: AI coding agents need better network transparency. Anthropic’s own Claude Code data usage documentation says the tool runs locally but sends user prompts and model outputs over the network to interact with the model. The same docs describe operational metrics, optional feedback uploads, retention differences by account type, and ways to disable some telemetry. The environment variable reference also documents ANTHROPIC_BASE_URL as a way to route requests through a proxy or gateway.
That is all normal developer-tool territory. Proxies are normal. Abuse detection is normal. API providers wanting to know whether traffic is coming through an unofficial reseller is also normal. The part that makes developers itchy is when request behavior is only visible after someone reverse-engineers a binary. That is not a great look for a tool that asks to read source code, run shell commands, and push changes. Subtle, yes. Boring, no. Developer trust prefers boring.
A Coding Agent Is Not A Chat Window
A normal chatbot gets a prompt and returns text. That can still leak sensitive information, but the boundary is obvious: you typed something into a website or app. A coding agent lives in a much stranger place. It may see files, dependency manifests, internal comments, environment names, test logs, branch names, issue titles, and whatever else the user drops into context. If tools are enabled, it may run commands, call MCP servers, open URLs, edit files, and prepare commits.
That makes the request envelope matter. Not just the user’s visible prompt. The whole envelope: system text, tool descriptions, repo summaries, file snippets, hidden routing fields, headers, trace IDs, plugin data, feature flags, and telemetry toggles. Developers already review code diffs because the final patch matters. They should be able to review the network diff because the outgoing request matters too.
This is the same principle behind keeping a paper trail for AI-assisted code changes. A previous Notavello post on AI-written pull requests argued that teams need provenance without turning every PR into a courtroom exhibit. Network receipts are the same idea one layer earlier. They do not need drama. They need enough detail that a competent developer can answer, “What did this tool just send?” without attaching a debugger like it is 2009 and everyone has trust issues. Which, to be fair, they do.
What A Network Receipt Should Show
A network receipt should be a local, readable record of each model request and each non-model call the agent makes. It should not require packet capture. It should not require a paid enterprise dashboard. It should not require believing that the vendor would never do anything surprising because the landing page uses the word “secure” eleven times.
At minimum, every serious AI coding agent should expose these fields:
- Destination: the exact provider, host, and route class, such as direct API, vendor gateway, enterprise proxy, Bedrock, Vertex, or local model router.
- Identity used: whether the request used a personal subscription, an API key, an org-managed credential, SSO, or a shared gateway key.
- Model and mode: the model ID, agent mode, fast mode, extended thinking setting, context window assumptions, and fallback model behavior.
- Prompt envelope summary: system messages, tool definitions, repo summaries, attached file list, and whether hidden or generated system context was included.
- Content scope: which files, snippets, terminal output, images, or tool results were sent, ideally with paths and hashes when full text is too sensitive to display by default.
- Metadata: request headers, feature flags, trace IDs, proxy hints, cache settings, client version, and any provider-specific fields added to the request body.
- Telemetry status: whether usage metrics, error reporting, surveys, feedback bundles, or OpenTelemetry exports were enabled for that session.
- Retention path: the applicable retention policy or a link to the account-level setting that controls it.
This does not mean dumping raw secrets into a pretty log file. A good receipt should redact API keys, tokens, cookies, and known secret formats by default. It should still tell the truth about categories and routing. “Sent 4 files from /billing and 712 lines of terminal output to provider X through proxy Y” is useful. “Trust us” is a scented candle.
The Proxy Problem Is Real, Hiding It Is Still Dumb
There are legitimate reasons for AI companies to inspect routing behavior. Providers have to enforce account terms, detect quota resale, stop credential abuse, investigate scraping-style usage, and defend against model distillation attempts. A custom base URL can be a strong signal that traffic is not flowing through the default path. Enterprises also use custom gateways for completely boring reasons: cost tracking, data loss prevention, audit logging, model routing, regional controls, and centralized key management.
That is exactly why hidden behavior is the wrong answer. The same signal can mean “unauthorized reseller” or “large company doing responsible platform engineering.” If a tool treats gateway users as suspicious by default, it should say so. If a feature is disabled behind a proxy, say so. If extra classification metadata is sent when a custom endpoint is used, say so. Put it in the receipt, the docs, the admin console, and the changelog. There, fixed. No invisible punctuation required.
Vendors sometimes act as if transparency gives attackers a free playbook. That argument has a shelf life of about twelve seconds in developer tools. Attackers can reverse-engineer binaries, patch clients, change hostnames, strip headers, and route through fresh infrastructure. The people most affected by obscure behavior are usually the honest ones: internal platform teams, security reviewers, researchers, and developers debugging why the official tool behaves differently behind the company gateway.
How To Audit Your Own Setup This Week
You do not need to become a full-time reverse engineer to get a handle on AI coding agent traffic. Start with the boring checks. They catch most of the expensive surprises.
- Print the environment: check variables such as ANTHROPIC_BASE_URL, provider-specific base URLs, proxy settings, telemetry flags, OpenTelemetry settings, and custom headers before launching the agent.
- Use a clean shell profile: run the agent once from a minimal environment so old exports, shell aliases, and forgotten proxy variables cannot quietly change behavior.
- Check the vendor status command: if the tool has a status, config, doctor, or diagnostics command, capture it before and after authentication.
- Turn on local logging where available: prefer logs that summarize request categories and file lists without storing raw secrets forever.
- Review gateway logs: if traffic flows through LiteLLM, Kong, an internal proxy, Bedrock, Vertex, or another gateway, compare what the agent says it sent with what the gateway saw.
- Disable nonessential telemetry for sensitive repos: use the documented controls, then verify with logs or the gateway that the setting did what it claimed.
- Separate experiments from production work: do not test plugins, MCP servers, remote control, or new agent modes inside the repo that contains payroll exports and prod credentials. This should not need saying. It does.
The goal is not paranoia. The goal is repeatability. A team should be able to say, “This agent can read these directories, call these tools, send this kind of context, through this gateway, under this retention policy.” If that sentence cannot be completed, the setup is not production-ready. It is a demo with a company badge.
What Tool Vendors Should Ship Next
The best fix is not another privacy page with a stock photo of a lock. AI coding tools should ship a request transparency layer as part of the product. A local “request preview” command would let developers inspect the next model call before it leaves the machine. A session receipt would summarize what actually happened after the fact. An admin policy could require receipts for managed repos, CI agents, and gateway-routed sessions.
The receipt should be exportable as JSON for security teams and readable as plain text for normal humans. It should have stable field names, versioned schemas, and a clear distinction between user content, tool content, generated system context, routing metadata, telemetry, and provider controls. If a tool adds a hidden system line, it belongs in the receipt. If a tool injects today’s date, user email, repo metadata, plugin instructions, or a trace context, it belongs in the receipt. If the model provider receives it, the developer should not have to guess.
There is also room for a small industry convention here. Developer tools already understand lockfiles, ignore files, environment variables, and OpenTelemetry. A simple ai-request-receipt.json schema would be more useful than another round of “responsible AI” PDFs. Put the machine-readable truth next to the work. Let teams diff it. Let gateways validate it. Let security tools alert on surprising destinations or new metadata categories.
Trust Lives In The Boring Layer
The funny thing about developer trust is that it is rarely won by the impressive demo. The demo gets the install. Trust comes later, when the tool behaves predictably during the ugly parts: auth failure, proxy routing, telemetry opt-out, log redaction, billing limits, file permissions, and network calls.
AI coding agents are becoming part of the development stack. That means they need the same boring transparency developers expect from package managers, CI systems, cloud SDKs, and database clients. Show the endpoint. Show the payload class. Show the metadata. Show the retention path. Show what changed between versions.
The Claude Code marker debate will eventually fade into the usual archive of internet arguments: hot takes, screenshots, partial reproductions, and people being wrong in high definition. The durable rule should remain. When a coding agent can see the repo and speak to the network, it owes the developer a receipt.