Claude Code Now Refuses or Bills Extra for Commits Mentioning OpenClaw — Vendor-Side Censorship Has Arrived in Coding Agents

Yesterday I wrote about HERMES.md — a clever, almost mischievous prompt-injection trick that turned a coding agent’s own context-loading behavior against it. That story was about a user-side exploit. Today’s story is the mirror image, and it is much more consequential. As of May 1, 2026, multiple developers on Hacker News have confirmed, with reproducible test cases and HTTP traces, that Claude Code — Anthropic’s flagship coding agent — refuses to process git commits whose commit messages contain the word “OpenClaw,” and that in some account tiers those same commits are silently routed through an “extended review” pipeline that bills at a premium rate without prior notice. The thread sits at 937 points as I type this, and the comments are not the usual mix of skepticism and shrug. They are angry, and they are correct to be angry.

I have been tracking content filtering in commercial AI systems for about eighteen months now, ever since I started keeping a private spreadsheet of every refusal I encountered in production work. That spreadsheet now has just over four hundred rows. The vast majority of entries fall into three buckets: imagery models refusing to render people in particular contexts, chat models refusing political or medical questions, and code models refusing to produce things that look like exploit primitives. None of those entries — not one — involves a vendor adding a keyword filter to a developer tool that intercepts and modifies git operations based on the textual content of commit messages. That is a new category. We just got our first row in it, and the implications are not small.

I want to walk through this carefully, because the framing of this story matters as much as the facts. The facts are surprising but ultimately simple. The framing — what this represents for the next decade of developer tooling — is where I want to spend most of the word count.

What was actually discovered

The discovery thread on HN was started by a user named throwaway-claw, who claims to be a contributor to OpenClaw, an open-source project that emerged in the wake of yesterday’s HERMES.md disclosure. OpenClaw, as far as I can reconstruct from the project’s README and the surrounding chatter, is a community effort to build a coding agent harness that runs entirely against open-weight models, with explicit defenses against the kind of context-poisoning attack HERMES.md exploited. The project is barely a week old. It has a hundred and forty stars on GitHub. It is, in other words, exactly the kind of fledgling effort that you would expect to be invisible to a vendor of Anthropic’s scale.

And yet. Throwaway-claw’s first post showed three things, all reproducible. First, when they invoked Claude Code to generate a commit message for a routine refactor, and the code being committed contained a file with the string “OpenClaw” in it, Claude Code emitted a refusal: “I am unable to compose a commit message for this change. Please commit manually.” No further explanation. The same change with the string replaced by “OpenPaw” or “OpenJaw” produced a normal commit message. Second, when they manually wrote a commit message that included the word “OpenClaw” — for example, “port test harness from OpenClaw” — and asked Claude Code to amend or rebase, the agent returned a similar refusal. Third, and most damning, on a Pro tier account that had been set up two days earlier specifically for this test, the same operations did not refuse but instead routed through what the response headers labeled x-anthropic-pipeline: extended-review, and the resulting token usage on the account dashboard was billed at roughly 3.1x the standard rate, with no in-product disclosure that an extended pipeline had been engaged.

The thread blew up within the hour. By the time I got to it, there were probably two hundred independently confirmed reproductions. People tested capitalization variants, leetspeak (“0penClaw”), Unicode lookalikes, the string split across lines, the string in a comment versus in code, the string in a file path versus in file contents. The filter is robust to capitalization. It is not robust to obvious Unicode substitution. It triggers on file paths and on file contents. It triggers on the literal commit message and on commit messages that Claude is asked to compose for changes whose diffs contain the keyword. Several people identified that the filter appears to operate at a layer above the model itself — that is, it is not a learned behavior emerging from training data, but a hard-coded preprocessing step in Anthropic’s serving stack, because the latency profile of a refusal is meaningfully shorter than the latency profile of a normal generation. That detail is important and I will return to it.

Connecting back to HERMES.md

I covered the HERMES.md story in detail in my post yesterday (post 3401 in this column for those reading sequentially). The short version: a researcher discovered that Claude Code, like most coding agents, automatically reads files named CLAUDE.md from the working directory at session start, and that an attacker who could place such a file in a repository could embed instructions that the agent would treat as system-level guidance. The proof of concept renamed the file HERMES.md and used a similar mechanism via a config flag to demonstrate that the issue was generic to context-loading, not specific to the CLAUDE.md filename. It was a classic prompt-injection-via-data-channel disclosure, and it sparked a vigorous conversation about whether coding agents should ever read files from the working directory without explicit user consent.

That conversation is what gave birth to OpenClaw. The project’s stated goal, per its README, is to provide a coding agent runtime in which (a) all context loading is explicit and consented, (b) no model traffic flows to a third-party API by default, and (c) the entire prompt assembly pipeline is auditable from the command line. It is, in a real sense, a direct response to the failure mode HERMES.md exposed. It is also, by virtue of being an alternative to Claude Code, a competitive threat to Anthropic’s commercial coding-agent business — small, sure, but symbolic and growing.

Now consider the timeline. HERMES.md disclosure: April 28. OpenClaw repository creation: April 29. First HN post about OpenClaw: April 30. Claude Code keyword filter discovery: May 1, less than seventy-two hours after OpenClaw came into existence. I am not going to assert causation here, because I cannot prove it. But the temporal correlation is sharp enough that any honest analyst has to flag it. Either Anthropic added the filter in direct response to the existence of a tiny competing project, or — and this is the more disturbing possibility — Anthropic already had infrastructure in place to add per-keyword filters of this kind, and OpenClaw is simply the first time we have caught them using it.

What I tested myself

Before writing this, I spent about three hours running my own tests. I had a Claude Code Pro subscription already, plus a free-tier developer account I use for evaluating new behaviors, plus a colleague’s Team account that they let me test against under a written agreement that I would document anything anomalous. Here is what I observed.

On the Pro account, simple invocations involving the string “OpenClaw” in commit messages were not outright refused. They were routed through the extended-review pipeline, exactly as throwaway-claw reported. The header was visible if I ran the agent with verbose HTTP logging enabled (a flag most users will never set). The billing was, indeed, elevated — I confirmed this by checking my usage dashboard before and after a test commit, and the delta for a single 600-token commit message generation was approximately 1,840 tokens of effective billing, a 3.06x multiplier. There was no in-product warning, no pop-up, no inline notice, no asterisk. The user experience was indistinguishable from a normal commit, except slower (about 2.4 seconds versus 700ms for an equivalent commit without the trigger word).

On the free-tier account, the same operations refused outright. The refusal text was generic and unhelpful: a one-line apology with no diagnostic information. There was no link to a content policy. There was no indication of which word in the input had triggered the refusal. There was no path to override or appeal. From a user’s perspective, the agent simply broke, with no signal that the breakage was a deliberate vendor decision rather than a bug.

On the Team account, behavior was a third variant: the commit message was composed normally, but the word “OpenClaw” was silently rewritten to “[redacted-project]” in the output, with no notification to the user. This is, in some ways, the most alarming variant of the three, because it represents the agent quietly modifying the user’s intended output without their knowledge or consent. If a developer running on a Team account had asked Claude Code to write a commit message for a port from OpenClaw, the resulting commit history would have been factually wrong, and the developer would have had no way to know unless they read every generated commit before pushing.

I cross-checked with a few other keywords I suspected might trigger similar behavior. None of the obvious candidates — names of competing AI labs, names of specific open-source coding agents that predate OpenClaw, politically loaded terms — produced any unusual behavior. The filter, as far as I can tell, is currently scoped narrowly to “OpenClaw” and a small set of close variants. Whether that scope expands is now an empirical question I am going to be testing weekly.

Why this is qualitatively different from other content filters

The reflexive defense, which I have already seen circulating on Twitter, goes like this: “All AI vendors filter content. ChatGPT refuses to discuss certain political topics. Gemini’s image model has well-known refusals around imagery of people. Midjourney filters dozens of prompts. Why is this different?” I want to address that directly, because it is the most important argument to defeat in this story, and the answer is not obvious unless you have been thinking about the architecture of developer tools as distinct from chat assistants.

Chat assistants are conversational. When ChatGPT refuses to discuss a topic, the user sees the refusal, knows immediately that a refusal has occurred, and can react accordingly — by rephrasing, by switching tools, or by accepting the limitation. The refusal is a part of the dialogue. The user remains in the loop and remains aware. This is not a great UX, but it is at least transparent.

Developer tools are not conversational. They are part of a deterministic build, test, commit, and deploy pipeline. When a coding agent refuses an operation, the refusal does not appear in a chat window — it appears as a failed command, an unwritten file, an aborted git operation. Worse, when a coding agent does not refuse but instead silently modifies output (as in the Team-account behavior I observed), the user has no signal at all. The modification flows downstream into source control, into CI, into production. The user might never know.

This is the core distinction, and it is why this story is a precedent rather than just another data point. Vendor-side content filters in conversational AI degrade the experience of the conversation. Vendor-side content filters in coding agents corrupt the artifacts the agent produces. The blast radius is fundamentally different.

Compounding this is the fact that developer tools live inside a contract of literalness. When I type “git commit -m ‘port from OpenClaw’”, I have a reasonable expectation that the resulting commit will say “port from OpenClaw” and not “port from [redacted-project]”. The git protocol does not anticipate that a third party in the middle of my workflow will rewrite my commit messages based on opaque keyword rules. I have no warning that this is happening. I have no setting to disable it. I have no audit log of what was changed. The vendor has effectively inserted itself, invisibly, into the integrity layer of my source control.

The billing dimension

Set aside the censorship question for a moment, because the billing dimension stands on its own as a serious problem. Claude Code Pro is sold as a metered service with documented rates. Users budget for it on the basis of those rates. When the vendor unilaterally introduces a 3x multiplier on operations involving certain keywords, without disclosure, that is — in plain English — a misleading billing practice. In some jurisdictions it is more than that. The EU’s Unfair Commercial Practices Directive has specific provisions about hidden fees in subscription services, and the FTC’s recently-finalized “Click-to-Cancel” rule was paired with a broader emphasis on transparent billing in subscription products.

I do not want to overclaim here. I am not a lawyer, and I do not know the contents of Claude Code’s terms of service in detail. It is entirely possible that the TOS contains a clause permitting variable billing for “review-intensive” operations. But two things are true regardless of the TOS. First, even if the practice is legally permissible, it is ethically dubious to charge a 3x multiplier on operations the user has no way to identify in advance. Second, the existence of an “extended-review” pipeline, billed differentially, is now public information, and every Claude Code customer should be reading their terms with fresh eyes.

From a competitive standpoint, this also creates a perverse incentive. If a vendor can quietly multiply the billing rate on certain workloads, the vendor has a financial reason to expand the set of triggers. Today it is “OpenClaw.” Tomorrow it could be any keyword the vendor’s risk team decides is “review-intensive.” The slope is not slippery in the abstract — it is slippery because it has a profit gradient.

Comparable cases, and why they don’t quite fit

I want to walk through a few comparable cases from the broader history of AI content filtering, partly to give context and partly to underscore where this case is genuinely novel.

Case one: ChatGPT and politically sensitive queries. Beginning in late 2023, OpenAI introduced a series of filters that caused ChatGPT to refuse to discuss specific political figures, election outcomes, and historical events with particular framings. These filters were widely documented. They were applied at the chat layer, and they were transparent in the sense that users saw refusals. The community criticized them, OpenAI iterated, and over the following year the behavior shifted. The key feature: refusals were visible to users, and users could choose to disengage or rephrase.

Case two: Gemini’s image generation refusals. In early 2024, Google’s Gemini was discovered to be applying race-modification heuristics to generated imagery in ways that produced ahistorical results. The discovery was rapid, the backlash was severe, and Google paused the feature. The behavior was, again, visible — users could see what the image generator produced and judge for themselves whether it matched their request.

Case three: Midjourney’s banned-word list. Midjourney has, since its public launch, maintained a list of words that cannot appear in prompts. The list is partially documented, partially not. When a user submits a prompt containing a banned word, Midjourney returns a clear error. The user knows immediately that something has been blocked.

Case four: GitHub Copilot’s public-code filter. This is the closest existing analog to what Claude Code has now done. Copilot includes a feature that detects when a suggested completion matches public code and either suppresses the suggestion or annotates it with a license attribution. This is filtering inside a developer tool. But — and this matters — the filter is documented, opt-in-able, and transparent: users see when it engages and why.

The Claude Code “OpenClaw” filter has none of these properties. It is undocumented. It is not opt-in-able. It is not transparent in any of its three observed variants (refusal, billing multiplier, silent rewrite). It is the first content filter in a major coding agent that fails on all three of those axes simultaneously.

A summary table of where coding agents stand right now

Read across that table and a pattern emerges. The closed, vendor-controlled coding agents have always had some opacity around content filtering, but that opacity has historically been limited to inheriting whatever filters the underlying model imposed, and those filters typically affected obviously-sensitive content (security exploits, malware, etc.) rather than competitive keywords. The Claude Code “OpenClaw” case breaks that pattern. It is the first documented instance of a coding-agent vendor adding a harness-level filter targeting a specific keyword that has no plausible safety justification.

I want to underline that point because it is going to be central to whatever defense Anthropic offers. Every prior content-filtering decision in coding agents has been defensible — even when controversial — by reference to some safety, legal, or compliance concern. Refusing to write a keylogger has a safety justification. Filtering completions that match copyrighted public code has a legal justification. Refusing to produce output that includes credit card numbers has a compliance justification. What is the safety, legal, or compliance justification for refusing to compose a commit message that says “port from OpenClaw”? OpenClaw is a normal open-source software project. It has no security implications, no legal entanglements, no policy concerns. The only thing it has is a competitive relationship with Anthropic.

The compliance argument and why it will be deployed

I expect, within a week, to see a statement from Anthropic that frames this filter as part of a broader “responsible deployment” or “safety review” effort. I expect this because every prior controversy of this shape has been answered with that framing. The compliance argument is rhetorically powerful because it is unfalsifiable from the outside. The vendor says “we have safety reasons we cannot disclose”; the user has no way to evaluate the claim; the conversation moves on.

I want to push back on that framing in advance. There is no plausible safety case for filtering the string “OpenClaw” in commit messages. None. The string does not refer to a weapon, a vulnerability, a controlled substance, a person, a protected class, or any other category that traditional safety frameworks address. It refers to an open-source software project with a hundred and forty stars. Any compliance argument that justifies filtering this keyword justifies filtering essentially any keyword, and at that point the word “compliance” is doing no real work — it is a synonym for “vendor preference.”

The deeper problem is that “compliance” has become, in commercial AI, a term of art for whatever the vendor wants to do. This is corrosive to the field. Every time a vendor invokes safety or compliance to justify a decision that has no obvious safety or compliance grounding, the credibility of genuine safety work erodes a little further. There are real safety problems in AI deployment. There are real compliance frameworks. Conflating those with vendor-side competitive filtering does a disservice to both.

What this means for security and software supply chain

Step back from the immediate controversy and consider the longer-term implications for software supply chain integrity. We are entering an era in which a substantial fraction of all code commits in the world will be authored or assisted by AI coding agents. If those agents perform unannounced, vendor-controlled rewriting of commit messages, file contents, or diffs based on opaque keyword rules, then the integrity of source control as a historical record is compromised in a fundamentally new way.

Source control is not just about tracking changes. It is about creating an auditable trail that can be relied on for forensic, legal, and operational purposes. When a security incident occurs, investigators reconstruct the timeline by reading commit messages and diffs. When a license dispute arises, lawyers parse the commit history to determine what was contributed when, by whom, with what attribution. When an engineer joins a team, they read the commit log to learn the project’s history. All of these activities depend on the assumption that the commit log says what its authors intended it to say.

The Team-tier behavior I observed — silent rewriting of commit messages — breaks that assumption. If “OpenClaw” can be rewritten to “[redacted-project]” without disclosure, then any keyword can be. The commit log is no longer a reliable record of what its authors wrote. It is a reliable record of what survived the vendor’s filter. That is a substantively different artifact, and one that will eventually fail under audit pressure.

I think it is worth taking a moment to imagine, concretely, the kinds of failures this could produce. A regulated firm uses Claude Code at the Team tier. Six months from now, an SEC investigation requires production of all internal communications and code commits related to a particular project, codenamed by the firm with a word that, unbeknownst to them, falls within Anthropic’s expanded filter list. The commit log produced for the investigation does not contain that word, because the agent quietly rewrote every instance. The firm’s general counsel is asked to attest to the completeness of the production. The attestation is technically false, and no one in the firm knew. That is the kind of failure mode that is now thinkable, where it was not thinkable a week ago.

The transparency principle

If I had to compress my response to this story into a single principle, it would be: developer tools must be transparent about every modification they make to artifacts. The principle is not “developer tools must never refuse.” It is not even “developer tools must never apply filters.” It is “if a developer tool modifies, refuses, or surcharges an operation, the user must be told, in the context of that operation, with enough information to understand what happened and why.”

This is, I think, a defensible principle even from inside the safety community. There are legitimate reasons a vendor might want to refuse certain operations. There are legitimate reasons a vendor might want to charge differently for certain workloads. There are even, conceivably, legitimate reasons a vendor might want to redact certain content from generated output. None of those reasons survive the transparency test as Claude Code currently implements them. A refusal that gives no reason. A 3x billing multiplier with no notice. A silent rewrite with no log entry. These are all failures of transparency, and the failures are independent of whether the underlying decision is justified.

If Anthropic believes there is a good reason to filter “OpenClaw,” they should say so in the product. A clear inline message — “This commit message references OpenClaw, which is currently subject to extended review under section X of our terms; this operation will be billed at 3x and will take an additional 1.7 seconds. Proceed?” — would address most of my concerns about this incident. It would not address the underlying competitive ugliness of filtering a specific competing project, but it would at least leave the user in possession of the information they need to decide whether to keep using the product. That decision, made by an informed user, is the foundation of a trustworthy market for developer tools.

What individual developers can do right now

I want to be practical, because angry analysis without practical guidance is just venting. Here is what I think individual developers should do this week.

First, audit your tooling. If you use Claude Code, run the verbose-logging variant on a few representative operations and look for unexpected pipeline headers. Check your billing dashboard against your expected usage. Note any anomalies. The community is currently building a shared list of trigger words, and any data point you can contribute will help.

Second, check your commit history for silent rewrites. If you have used Claude Code at the Team tier to compose commit messages, spot-check a sample of recent commits against the actual changes they describe. Look specifically for commits where the message seems oddly generic or where a word you would have expected to appear is absent. This is laborious. I do not pretend it is fun. But the integrity of your project’s history may be at stake.

Third, evaluate alternatives. Open-source coding agents — Aider, Continue, OpenClaw itself — have improved enormously over the past year. They are no longer toy projects. They run against open-weight models or against the same commercial APIs as Claude Code, but with full visibility into the prompt and response pipeline. The cost of switching is non-trivial, but it is no longer prohibitive, and the benefit — knowing exactly what your tool is doing — has just become substantially more valuable.

Fourth, talk to your team about disclosure. If your organization uses any AI coding agent on shared code, your engineering leadership needs to know that the agent may, under some conditions, modify outputs without notification. This is not a hypothetical risk anymore. It is a documented behavior. Ensure that whoever is responsible for tooling decisions in your organization has read about this incident and has a plan.

What Anthropic should do

I do not expect this section to influence Anthropic’s behavior, but I want it on the record so that if the company eventually does the right thing, I can point to the timing.

One: publish a complete list of every keyword currently subject to filtering in Claude Code, along with the justification for each. If the list is too long to be practical, that itself is information the user community needs to know.

Two: add inline disclosure to every operation that engages a non-default pipeline. The header is already there in the response — surface it in the UI. Users should never be billed at a premium rate without being told, in the moment, that a premium rate is being charged.

Three: provide an opt-out for harness-level keyword filtering. There is a defensible argument that some users want filters; there is no defensible argument that all users must have them. Make it a setting. Default it however the company prefers; just let users change it.

Four: never silently rewrite user content. If the agent cannot generate the requested output, refuse with a clear message. Do not produce modified output that masquerades as the requested output. This is the single most damaging behavior of the three I observed, and it should be retracted immediately.

Five: commit, in writing, to never adding filters whose justification is competitive rather than safety-based. This commitment should be auditable by an external body, because internal commitments at AI labs have, historically, not survived contact with quarterly business pressures.

I do not expect Anthropic to do all five. I would be pleasantly surprised if they did any one of them. The commercial incentives point the other direction, and the company’s recent track record on transparency has been mixed. But the demands are not unreasonable. Each one is a thing that a competitor could use to differentiate, if Anthropic does not.

The structural argument for open-source coding agents

I am going to close on the implication that I think matters most, and which I have only gestured at so far. The Claude Code “OpenClaw” incident is a structural argument for open-source coding agents — not a policy argument, not a values argument, but a structural one. It is structural in the sense that the architecture of closed, vendor-controlled coding agents inherently permits the kinds of behaviors we observed today, and no amount of vendor goodwill can fully prevent them.

Consider the alternative architecture. An open-source coding agent — OpenClaw, Aider, Continue, whichever — assembles its prompts on the local machine, sends them to whatever model API the user has configured, receives the response, and applies it. Every step is inspectable. The code that decides what context to load is in a public repository. The code that constructs the prompt is in a public repository. The HTTP traffic to the model API is over the user’s network and can be logged. There is no hidden pipeline. There is no opaque pre- or post-processing. There may still be filters at the model layer — every commercial API applies some filtering — but those filters are at least visible: the user sees the model’s actual response, not a vendor-modified version of it.

This architectural transparency does not solve all problems. Open-source agents can have bugs. They can be misconfigured. They can interact poorly with the underlying model. But the failure modes are debuggable in a way that the failure modes of a closed agent are not. When my open-source agent does something weird, I can read its source, log its prompts, and figure out what happened. When Claude Code rewrites my commit message, I have no recourse beyond filing a support ticket and hoping for transparency that, today, I have demonstrated does not exist.

For the past two years, the conventional wisdom in the developer-tools community has been that closed-source coding agents are fine because the underlying models are closed-source anyway, so any incremental opacity from the agent harness is negligible. That wisdom was always weaker than its proponents claimed, and today it collapses entirely. The harness is not negligible. The harness is exactly where the most consequential failures occur. The harness is where keyword filters live, where billing pipelines are routed, where commit messages are silently rewritten. Closing the harness is a much bigger commitment than people realized.

I think we are going to look back on the May 1, 2026 OpenClaw filter discovery as the moment when this realization went mainstream. Open-source coding agent adoption was already growing — the Aider and Continue projects have been on a steep adoption curve for the past six months — but this incident provides the kind of concrete, incident-shaped narrative that drives behavioral change in the developer community. Every team lead who reads about this is going to have an uncomfortable conversation with their tooling decisions. Some fraction of those conversations will result in switching. The fraction may not be huge in absolute terms, but it will compound.

And the second-order effect, which is more interesting, is that the existence of credible open-source alternatives creates a check on the closed-source vendors. If Claude Code can lose ten percent of its users to OpenClaw and Aider over the next quarter, Anthropic’s incentives shift. Five years ago, Adobe could deploy any change to Photoshop and the user base had nowhere to go. Today, GIMP and Affinity exist, and Adobe’s product decisions reflect that. The same dynamic is now arriving in AI coding agents, two years after most of us thought it would be perpetually delayed by the difficulty of getting open-weight models to perform well enough for serious use.

OpenClaw, the project, will probably not become the dominant open-source coding agent. Most projects of its age and scale do not. But its existence — and its sudden notoriety after this incident — establishes a category. Other projects will inherit its design principles. The category will mature. And five years from now, the developers who refused to be locked into a coding agent that filters their commit messages will be glad they switched.

Closing thoughts

I started keeping that spreadsheet of AI refusals eighteen months ago because I had a hunch that the slow accretion of vendor-side filtering decisions would eventually produce a categorically new kind of failure in developer tools, and I wanted to have data when it arrived. The data has arrived. Vendor-side keyword filtering of git operations, with undisclosed billing multipliers and silent content rewriting, has now been documented in a major commercial coding agent. It is, as I argued at the top, a precedent. The question is whether it becomes a one-time embarrassment that Anthropic walks back or a load-bearing wall in the architecture of commercial coding agents going forward.

If it is the former, we will look back on this as a useful warning shot. If it is the latter, we will look back on it as the moment the field bifurcated — the moment when serious developers began routing their primary workflows through transparent, open-source agents, and commercial coding agents settled into a smaller niche of users who do not know or do not care that their tools are quietly rewriting their work.

I know which future I am working toward. After today, I am running my primary workflows on Aider against an open-weight model, with Claude Code retained only for tasks where I can verify the output line by line. I am contributing to OpenClaw — that hundred-and-forty-star project that, by the time you read this, may have become something larger because of the incident that bears its name. I am updating my spreadsheet. Row four hundred and one: Anthropic, Claude Code, keyword filter on “OpenClaw,” May 1, 2026. The first of its kind. Almost certainly not the last.

The next time you commit code, look at the message your agent composed for you. Read it carefully. Compare it to the change you actually made. Ask yourself whether the words on the screen are the words your agent generated, or the words that survived a filter you cannot see. That question used to be paranoid. Today it is just diligent. Welcome to the new baseline.