I tried to reproduce the OpenClaw case in Claude Code: my result contradicts the viral post
I published a hypothesis that was too strong.
The previous version of this post claimed Claude Code was refusing commits containing OpenClaw, and framed that as clear evidence of undocumented alignment in agent mode. Then I tried to reproduce it properly, with a public repo and a minimal matrix, and the data did not support that version.
I'm not going to polish that away.
The correct result is less explosive, but more useful: I could not reproduce the block on Claude Code 2.1.126.
Repro repo:
https://github.com/JuanTorchia/claude-openclaw-commit-matrix
Run report:
What the original claim said
The strong claim was not just "a commit subject containing OpenClaw fails".
The more interesting version was this: if openclaw.inbound_meta.v1 appeared in Git history, Claude Code could later block or redirect billing when running something as simple as:
claude -p "hi"That matters because it changes the diagnosis. A dumb filter over commit messages is one thing. A system that inspects repo history and changes Claude Code behavior because of a previous marker would be much more serious.
My previous post jumped too quickly toward that second reading without a clean enough repro.
That was the mistake.
What I tested
I built a public repo dedicated to the case:
https://github.com/JuanTorchia/claude-openclaw-commit-matrix
The point was to move the experiment out of my real repo and reduce it to something anyone could inspect:
- a new repo;
- controlled commits;
- simple prompts;
- before/after state;
- exact Claude Code version;
- a saved report in the repo.
The run I'm citing is this one:
Version tested:
Claude Code 2.1.126I tested a matrix of OpenClaw variants:
OpenClawopenclawopen-clawOpenClawin the commit bodyopenClawOpenclawOPENCLAWOpen Claw
The goal was not to prove the original report false. It was narrower: does the general claim "Claude Code blocks commits with OpenClaw" hold as a rule in my current environment?
Result
All 8 commits passed.
No block.
No visible billing redirect.
No refusal from Claude Code to operate on the repo because OpenClaw appeared in Git history.
That contradicts the original angle of my post.
The honest conclusion is:
I cannot claim the original report was false. I can claim the broad claim "Claude Code blocks commits with OpenClaw" does not hold as a general rule on Claude Code 2.1.126.
That distinction matters.
A repro that does not reproduce does not automatically invalidate the original event. There may be version differences, server-side flags, account state, region, billing, plan, session state, exact prompt, repo history, or timing. But it does invalidate a strong generalization.
My previous post generalized too much.
What we know
We know there was a viral report.
We know the strong case involved more than a word in a subject: it referred to openclaw.inbound_meta.v1 in Git history and later behavior from claude -p "hi".
We know my public repro on Claude Code 2.1.126 did not reproduce the block.
We know all 8 commit matrix cases passed.
We know that, at least on that version and in that environment, putting OpenClaw into commits is not enough to trigger the reported behavior.
That is much less dramatic than "Claude Code censors commits".
It is also much more defensible.
What we do not know
We do not know whether the original report happened exactly as described.
We do not know whether Anthropic changed something after the thread.
We do not know whether a server-side flag was active for some accounts.
We do not know whether the behavior depended on billing, plan, region, workspace, permissions, previous repo state, or some condition my harness did not replicate.
We do not know whether openclaw.inbound_meta.v1 was the real cause or just a correlation inside a more complex case.
And we do not know whether Claude Code has other policy layers over agent actions that can fail silently in other scenarios.
That last part still matters. But this case does not prove it.
The technical lesson
The lesson is not "Anthropic censors commits".
With the data I have today, that sentence is too strong.
The lesson is more boring and more important:
- viral reports without exact versions are fragile;
- agents need post-action validation;
- a system with billing, policy, and server-side flags can change behavior in ways your local repro cannot explain;
- if you are going to claim a tool blocked an action, you need HEAD before/after, logs, exact version, exact command, and observable state.
This applies to Claude Code, Cursor, Copilot CLI, and any agent that executes real tools.
When an agent says or seems to have done something, you verify the effect. You do not trust the model's narrative or the operator's intuition.
For commits, the minimum validation is boring:
before=$(git rev-parse HEAD)
# run the agent action
after=$(git rev-parse HEAD)
if [ "$before" = "$after" ]; then
echo "No new commit was created" >&2
exit 1
fiThat does not solve the OpenClaw mystery. But it stops an automated flow from believing something happened when it did not.
Public correction
The original post had more confidence than evidence.
The corrected version is this:
I tried to reproduce the viral OpenClaw case in Claude Code. I built a public repo, documented the matrix, and ran the cases on Claude Code 2.1.126. My result contradicts the broad claim that Claude Code blocks commits with OpenClaw as a rule.
I cannot prove the original report false.
I can say my repro does not confirm it.
And if the evidence does not support the headline, the headline changes.
Related Articles
The Birth and Death of JavaScript (2014): What Still Holds and What Doesn't
A 2014 talk predicted JavaScript would die, replaced by ASM.js. A decade later, JS is still alive — but the tension it identified is more real than ever. Here's what's worth extracting, what to ignore, and how to turn it into a concrete technical decision.
Formal Methods and the Future of Programming: What's Worth Trying and Where the Ceiling Is
Formal methods keeps surfacing on the technical radar as the solution the industry ignored. My read: the problem it points to is real, but the recipe floating around omits costs that change the equation entirely.
Authentication tokens: JWT, Paseto, and session tokens — the decision tree I always needed
There's no such thing as the perfect token — only the right token for your system's threat model. A practical decision tree with real technical judgment for choosing between JWT, Paseto v4, and opaque session tokens in TypeScript. No dogma, no made-up benchmarks.
Comments (0)
What do you think of this?
Drop your comment in 10 seconds.
We only use your login to show your name and avatar. No spam.