Clawd-Code is MIT, calls itself a port of the real Claude Code, and ships a stub author email

MIT-licensed, and described as a port of the real source

The readme's subtitle is a complete Python reimplementation based on real source, and a line beneath it says it went from a TypeScript original to a Python rebuild.

The project it is rebuilding is a proprietary terminal agent from a commercial vendor. That is the first fact to hold on to, and the licence is the second: the package metadata declares MIT.

Those two claims are in tension. A permissive licence grants rights in the copyright holder's own work, and it cannot grant them in someone else's closed-source code. If the port was written by reading the original, the MIT grant covers the Python that resulted and not the design it was derived from. If it was written from the documented behaviour, then the subtitle overstates the provenance.

The readme does not resolve which it is, and no attribution to the original project appears in the credits.

That is not a reason to skip the repository, which contains real work. It is a reason to know what you are running before you point it at a codebase, because an agent with file, shell and web tools is a different risk when you believe it is a clean-room reimplementation.

Around 659 stars and 323 forks against 8 open issues is a fork-heavy audience, which is what you would expect from something people want to modify rather than adopt.

The repository is Clawd-Code and the package metadata points at Clawd-Codex

The project has more than one name, and the ones disagree.

The repository is `Clawd-Code`. The readme's title is Clawd-Code, its install instructions clone that name, and its badge links point there. The package metadata names the distribution `clawd-codex`. The agent's own greeting introduces itself as Clawd Codex.

And then the URLs. All three project links in the package metadata, for the homepage, the repository and the documentation, point at a repository with a different suffix. The documented clone command points at the one it actually lives in.

So anyone who installs the package and follows its metadata to find the source arrives somewhere else, while anyone who follows the readme arrives in the right place. Which of the two exists is not something the repository says.

Two more metadata details sit in the same file. The author is a team with an email address at the reserved example domain, which is the placeholder every packaging tutorial uses, left in place in a published manifest.

And the development status classifier says alpha.

That sits directly under a description calling itself a complete reimplementation with a drop-in replacement experience, and under a readme that calls the project production-oriented in its first paragraph and complete in its status table.

Alpha and production-oriented are both in the repository. Neither is a typo for the other.

The banner advertises tool sandboxing and the status table says the permission system is unintegrated

Two systems in the status table are marked as unfinished, and they are the two the marketing copy leads on.

Context building is marked incomplete, with the note that initial prompt injection for the workspace, git history and a project instructions file exists but that deeper project understanding is still needed.

The permission system is marked incomplete too, with the shorter note that a framework exists and needs integration.

Now read the banner three sections above. One of its four claims is a programmable skill runtime with tool sandboxing. And the skills section says the markdown skill format supports project skills, user skills, named arguments and tool limits.

Tool limits are the enforcement surface. If the permission system is a framework that needs integration, then a skill declaring which tools it may call is a declaration with nothing behind it.

The roadmap agrees with the status table rather than the banner. The fourth phase, covering context, permissions and recovery, is marked in progress. The two later phases, for protocol support and plugins, and for Python-specific extensions, are both marked as not started.

So there are three separate places the readme describes this project: a banner, a status table, and a roadmap. They disagree, and the two more specific documents agree with each other and not with the one a visitor reads first.

Protocol support is marked complete in the tool table and not started in the roadmap

One row of the tool table is worth pulling out on its own.

The tool system lists nine categories and every one of them is marked complete. File operations, five tools. Shell execution. Two web tools. Two interaction tools. Three task-management tools. Three agent tools. Three configuration tools including plan mode and scheduling. Protocol server tools and resources. And four others covering a language server, worktrees, skills and a tool search.

The protocol row says complete. The roadmap says the phase covering protocol support, plugins and extensibility has not started.

Both cannot be right, and the same applies to the configuration row, since a plugin system is in the same unstarted phase as plugins would need.

The tools in the complete rows are specific enough to check individually, which is the useful part. A tool that exists with a known name and a known input shape is something you can call. A phase marker is a claim about intent. The tool table is the one to trust.

Counting the named tools in those nine rows gives twenty-five. The status table above them claims thirty or more tools implemented.

Twenty-five tools named against a claim of thirty or more

The count does not close, and it is worth being precise about how far.

The nine categories name twenty-five tools between them: five for files, one for shell, two for the web, two for interaction, three for task management, three for agent tools, three for configuration, two for protocol access, and four in the catch-all row.

The status summary says thirty or more tools. So five tools are claimed and not named, and there is no place in the readme that says which five.

That is not a serious problem on its own. Tool counts in a status summary are usually rounded up, and a project that has twenty-five named tools and claims thirty has, if anything, under-promised.

It matters because of what else in the same document is counted the same way. The REPL summary says six or more built-in commands, and the REPL commands table below it is truncated in the copy available. The tests row says present rather than complete, and describes them as core suites covering skills, providers, the REPL, tools and context. The documentation row says complete, with ten or more documents.

Three of the four summary counts are hedged with a floor. One, the tools, is not hedged and does not match its own detail.

The feature list document, linked from the roadmap section, is where the per-item status is meant to live, and it is the file to read if the summary is going to disagree with the tables.

requirements.txt omits a runtime dependency and ships the dev dependencies

The two dependency declarations in this repository disagree, and the documented install uses the less accurate one.

The package metadata lists seven runtime dependencies: three provider libraries, a dotenv loader, a terminal formatting library, a prompt-completion library, and a tokeniser with a floor.

The requirements file lists six. It has the three provider libraries, the dotenv loader, the terminal library and the prompt library, with floors. The tokeniser is not in it.

The quick start installs from the requirements file, so following the readme gives you an environment missing a package the project declares it needs:

git clone https://github.com/GPT-AGI/Clawd-Code.git
cd Clawd-Code

# Create venv (uv recommended)
uv venv --python 3.11
source .venv/bin/activate

# Install
uv pip install -r requirements.txt

The same file then lists three development dependencies in the same block: a build frontend, an upload tool and a test runner. So the documented quick start installs the packaging and testing toolchain as part of setting up to chat with an agent.

And a lockfile is committed at the root. So there are three mechanisms here: a package manifest with unpinned dependencies, a requirements file with floored dependencies that omits one of them and adds three extras, and a lockfile that the documented install never touches.

The lockfile is the artifact that would make an install reproducible, and the one install path in the readme is the one that bypasses it.

API keys are base64-encoded and the config directory is committed

The interactive setup asks you for a provider, an API key, an optional base URL and an optional default model, then writes the result to a configuration file in your home directory.

The example of that file shows the key field holding a base64-encoded key. Base64 is an encoding, not a cipher: anything that can read the file can decode it with one command, and so can anything that has read your shell history.

So the keys for three providers sit in one JSON file in your home directory in a reversible encoding, and there is no passphrase step described anywhere in the setup flow.

Related to that, a configuration directory is committed at the repository root. A directory with that name, in a project whose setup flow writes to the same name in the home directory, is exactly the kind of thing that gets committed with real keys in it before anyone notices.

Two smaller choices round out the picture. All three provider libraries are hard runtime dependencies, so installing this pulls in three vendor SDKs even if you use one of them. And the console entry point imports a top-level package whose name is the conventional source directory name, which setuptools is configured to include by wildcard.

Editorial conclusion

Read Clawd-Code as a weekend project that got a good way, and check its status table rather than its banner. The tool surface is broad and the tests exist, but the two features its headline advertises are the two the table marks incomplete, and the version metadata says alpha. Two things to settle before you use it. The provenance claim and the MIT licence are in tension, so decide for yourself what you are comfortable running. And the API keys you save are base64-encoded, not encrypted, so treat that config file the way you would treat a plaintext key.

Frequently asked questions

Official sources

1. GPT-AGI/Clawd-Code on GitHub
2. Issues
3. License: MIT
4. README