ClawGod: a runtime patch for Claude Code that unlocks internal features and removes restrictions

What ClawGod patches, and who it is for

ClawGod is not a Claude Code client. The README states this explicitly: it is a runtime patch applied on top of the official Claude Code binary. That distinction matters, because it means the tool does not reimplement the agent loop, the tool set or the model calls. It edits the program you already have.

The audience is narrow and specific. You need Claude Code installed as the native Bun standalone binary, and you need to be willing to run a patcher that rewrites parts of that binary's extracted JavaScript. In exchange, the README lists four categories of change: feature unlocks (internal user mode with 24 or more hidden commands such as /share, /teleport, /issue and /bughunter), restriction removals, geo-steganography neutralization, and reliability fixes.

Some of those fixes are the most defensible part of the project. The third-party cache fix auto-disables the x-anthropic-billing-header when baseURL is non-Anthropic, because the header's per-request cch field breaks prompt-cache hit rate on proxies such as DeepSeek, OneAPI, Bedrock and vLLM. The README notes you no longer need to set CLAUDE_CODE_ATTRIBUTION_HEADER=0 yourself. That is a concrete, testable behaviour change, not a slogan.

How the patcher survives Claude Code upgrades

The mechanism is re-extraction. Claude Code ships as a compiled Bun standalone binary, and the patcher pulls the embedded cli.js back out, applies its edits, and runs the result under the Bun runtime. The README says that as Claude Code updates, ClawGod automatically re-extracts and re-patches against the new version on the next launch.

That design explains the repository layout. There is an install.sh and an install.ps1 at the top level, a src directory holding the patch logic, a build.js, and a tools directory. The primary language is PowerShell, which is unusual for a cross-platform tool and suggests the Windows path received early attention. There is a compat-daily workflow in .github, referenced by a badge in the README, which implies the project tracks Claude Code version compatibility on a daily cadence rather than only at release time.

The geo-steganography section is where the patching gets surgical. According to the README, the system prompt encodes user location through Unicode apostrophe variants (U+0027, U+2019, U+02BC, U+02B9) and a date separator that differs between the CN timezone and elsewhere. A separate client-side probe checks timezone, matches the proxy hostname against an XOR-obfuscated blocklist of more than 100 domains, and scans for CN-LLM vendor keywords in the base URL. ClawGod patches the date string to always use ASCII apostrophes and an unmodified date format, forces the detection probe to return null, and forces the apostrophe selector to ASCII as a second layer. Whether you agree with the goal, the description is specific enough to audit.

Installing ClawGod and running a first patched session

The README lists prerequisites that must be installed before the ClawGod installer runs: the native Claude Code binary, ripgrep (required by Claude Code's Grep tool), Node.js >= 18 for the patcher, and Bun as the runtime for the patched cli.js. Bun is auto-installed if missing. ripgrep is not, so install it first.

On macOS or Linux, installation is a single piped script from the latest release. Because it is a pipe-to-shell, download and read it first if you care what runs on your machine.

curl -fsSL https://github.com/0Chencc/clawgod/releases/latest/download/install.sh | bash

Windows uses the PowerShell equivalent, also from the latest release:

irm https://github.com/0Chencc/clawgod/releases/latest/download/install.ps1 | iex

After installation, three commands exist. The README says the green logo indicates a patched build and orange indicates the original.

claude              # Patched Claude Code (replaces the official launcher)
clawgod             # Same as `claude`, explicit & guaranteed entry point
claude.orig         # Original unpatched version (auto-backed-up)

The clawgod entry point is the one to remember. The README explains that on Windows, where claude.exe may shadow claude.cmd, clawgod.cmd always works, and that even after an official self-update overwrites claude, clawgod keeps running the patched build. If you only ever type claude, an upstream update can quietly take the patch out of your path until the next launch re-patches it.

Configuration lives in ~/.clawgod/provider.json, auto-created on first run. Setting apiKey lets you skip OAuth and point ClawGod at any Anthropic-compatible endpoint.

{
  "apiKey": "sk-ant-...",
  "baseURL": "https://api.anthropic.com",
  "model": "",
  "smallModel": "",
  "timeoutMs": 3000000
}

The README states that when apiKey is set, ClawGod injects it as ANTHROPIC_API_KEY and isolates from ~/.claude/settings.json. Lean Settings, a three-level token optimization for that same settings file, is toggled with claude --lean-on (default), claude --lean-max (which additionally removes Plan mode, Agent Teams and bundled skills) and claude --lean-off (restores all tools). The README calls these non-destructive and persistent across updates, and notes you can opt out of a single setting by writing it yourself, for example "disableArtifact": false.

Where ClawGod is the wrong tool

The largest limitation is structural: ClawGod depends on the internals of a binary it does not control. Re-extraction and re-patching only work while the patch targets still exist in the extracted cli.js. A Claude Code release that renames a function, moves the date-formatting logic, or compiles the relevant code differently can break a patch silently. The README's promise of automatic re-patching is a statement of intent, not a guarantee, and the compat-daily workflow exists precisely because compatibility has to be re-established continuously. The README does not document rollback beyond the auto-backed-up claude.orig command.

Restriction removal is a second boundary. ClawGod removes the CYBER_RISK_INSTRUCTION refusal, the URL restriction instruction, and the forced confirmation before destructive operations. If you work in an environment with a security review process, a patched agent that no longer asks before destructive actions is a policy question, not a convenience feature. Nothing in the README describes an audit log for those removed confirmations.

Finally, this is not a tool for anyone who wants a supported surface. There is no vendor relationship here, no compatibility guarantee from Anthropic, and the project is GPL-3.0 licensed, which has implications if you redistribute a modified build. If you need stability for a team, the honest answer is that you are trading it for features the upstream product gates.

How ClawGod differs from building your own harness

The obvious alternative is a separate agent harness, such as the OpenHarness project, which builds its own client around a model API rather than patching an existing one. The difference in approach is fundamental. A harness owns its own prompt, tool definitions and update cycle, so it never breaks because a vendor changed a function name. It also never inherits the vendor's internal commands, because those were never part of the public interface.

ClawGod takes the opposite bet: inherit everything the official binary does, then edit the parts you dislike. That gives you Claude Code's actual tool implementations, its Grep and Glob behaviour, and its prompt-cache handling, without reimplementing any of it. The cost is that you are always one upstream refactor away from a broken patch.

There is a middle option worth naming for third-party API users specifically. Several of ClawGod's reliability patches, such as the third-party cache fix and the 1h prompt cache allowlist, address problems that exist independently of the feature unlocks. If your only complaint is prompt-cache hit rate on a DeepSeek or OneAPI proxy, the README indicates the header fix is the relevant piece, and CLAUDE_CODE_ATTRIBUTION_HEADER=0 was the manual workaround it replaces.

Licence, upgrade cost and what to verify

ClawGod is GPL-3.0. For personal use that mostly means you can read and modify the source. If you distribute a modified build, the licence's source-availability terms apply, and this is worth checking with someone qualified if you plan to ship it inside a company. The README does not discuss commercial use or redistribution.

Upgrade cost is the part to weigh honestly. The project releases frequently (v1.9.2 and v1.9.3 landed on the same day, with v1.9.4 following about two weeks later), and the last push to the repository was on 2026-09-15. That cadence suggests active work, but it also means the patch surface moves. The compat-daily workflow is the mechanism that keeps Claude Code version compatibility honest, and it is the first thing to check when something stops working after an upstream update.

Before adopting, verify three things yourself: that your Claude Code install is the native Bun standalone binary rather than an npm wrapper, that ripgrep is on PATH, and that you are comfortable with the fact that the installer is delivered as a piped script from a GitHub release. Read install.sh or install.ps1 before running it. The README documents the prerequisites and the configuration file, but not the contents of the installer.

Editorial conclusion

Adopt ClawGod if you already run the native Claude Code binary, want the internal-user command set or the classifier and cache fixes, and are comfortable piping a release script into bash or PowerShell. Do not adopt it if you need a supported product surface, if your environment forbids patching vendor binaries, or if you rely on Claude Code's own self-update path without a fallback entry point. Before installing, confirm Claude Code, ripgrep, Node.js >= 18 and Bun are present, read install.sh or install.ps1 rather than piping it blind, and decide whether Lean Settings should stay at its default on level or be moved to max or off.

Frequently asked questions

Official sources

1. 0Chencc/clawgod on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases