Why Claude Code Refuses Repos That Mention OpenClaw

Theo of t3.gg posted a short experiment after Claude Code changed behavior in an empty git repository. The setup: an empty git repository, a single recent commit containing the string "OpenClaw" inside a JSON blob, and a direct invocation of Claude Code with an ordinary request. His report: "Claude Code will either refuse your request or bill you extra money. This is an empty repo, I'm just calling Claude Code directly." No source files or mention of OpenClaw in the prompt. The behavior change came from the commit history alone.

The experiment may not reproduce identically on every machine, but it shows that repository contents, including git history, are part of the prompt. When a string in a commit changes a session from "helpful" to "refused," the tool is sending context beyond what you typed.

The empty-repo experiment

An empty repository with one commit removes other variables. There is no source code for the model to object to, no CLAUDE.md steering it, no dependency manifest, and no README. The only content that differs from a fresh git init is one commit message. If behavior changes, the commit message is the cause.

This applies proper debugging methodology to a black box. Most complaints about agent refusals arrive as screenshots from 40-file repos with hours of session history, where many things could explain the behavior. Theo's version separates the claim into refusal and higher billing, then pins both to a single input. You do not need access to Anthropic's internals to run it.

The tweet does not establish why the string "OpenClaw" produces this. The name's cause does not affect the behavior described below.

Claude Code puts your git history in the prompt

Coding agents assemble a large system prompt from your environment before you type anything. Claude Code, at session start, gathers a snapshot that includes the current git status and recent commit subjects, the contents of CLAUDE.md files, and environment details like platform and working directory. As the session runs, more ambient content flows in through files it reads, search results, hook output, and tool results.

The model does not receive any of this with a label distinguishing what the human typed from what was on disk. Once assembled, it is one context window. A commit message written six weeks ago by a coworker has the same standing as text as the request you just made. Anything downstream that reacts to content in the request, whether that is the model's training or a separate policy layer, reacts to all of it.

This is why prompt injection against coding agents works. A malicious instruction hidden in a README or a dependency's error message enters the context through the same path as your git log. The OpenClaw case shows that content you did not write or intend as input can change how the tool treats you.

Why a string in a commit can change behavior

A policy check somewhere in the serving path may be sensitive to the string Theo observed. Model providers run classifiers and policy checks over requests, and those systems see the full assembled context, including your commit log. If a check keys on particular strings or topics and routes matching requests to stricter handling, a match anywhere in context, prompt or repo, would trigger it. The user experiences a refusal unrelated to what they asked.

The model may also respond differently without an explicit rule. It reads the history, notices the name, and associations from training or system-prompt guidance push it toward declining. These refusals are sensitive to incidental context. A word in scope can shift the response distribution.

A refusal should be cheap, but if sessions touching the string cost more, possible mechanisms include an additional processing pass whose tokens are billed to the user or the model sampling many more tokens before answering. Users cannot distinguish between these from the outside. When an agent's cost and willingness to work vary with ambient repo state and the vendor exposes no explanation, users are left doing black-box science on a product they pay for per token.

How to debug refusals you can't explain

Agent behavior can differ from one repo to another because the relevant context is invisible. Bisect the ambient context the same way Theo did.

# 1. Reproduce in a sterile environment
mkdir /tmp/repro && cd /tmp/repro
claude -p "your failing prompt"     # no git repo at all

# 2. Add git history back, one suspect at a time
git init
git commit --allow-empty -m "innocuous message"
claude -p "your failing prompt"

# 3. Check what history the tool can see
git log --oneline -10

Work outward from there. If the sterile run behaves and the in-repo run does not, the delta is in your repo. Check recent commit messages, CLAUDE.md files at project and user level, hooks that inject content, MCP servers that return it, and files the agent reads early. Claude Code's /context view shows what is loaded into the window and reduces the guessing. Strip candidates one at a time and rerun the same prompt. Find the minimal repro, one commit or one file that changes behavior. Vendors can act on that artifact.

Apply the same discipline to cost anomalies. If your bill spikes on one project, compare the ambient context before assuming the model got more expensive. Session token counts are visible. Compare a sterile run against an in-repo run with an identical prompt.

What coding agents send to vendors

Coding agents receive more than the prompt and files you mention. Their input includes everything in and around the working tree, plus what the vendor's serving stack adds or checks along the way. Secrets in git history travel to the vendor with every session. A teammate's commit message can alter agent behavior weeks later. Runs are not reproducible across repos with identical prompts, which matters when evaluating agents or building automation on top of one.

Agent CLIs should offer a way to dump the fully assembled request so users can see what the model saw during an inexplicable refusal. Context sources should be documented because they affect behavior. Server-side changes that alter refusal or billing behavior should have changelog entries because users cannot distinguish a model change from a policy rule without them.

The empty-repo test produces a repro a vendor engineer can run.