CometixCode: a Rust reimplementation of the Claude Code terminal UI

A 1:1 port, and what that means for the licence

CometixCode is a terminal-based AI coding assistant written in Rust as a 1:1 reimplementation of Anthropic's Claude Code, and the README puts the disclaimer at the top of the document: this is an unofficial project not affiliated with Anthropic, it is an independent reimplementation built by reading the published Claude Code CLI, Claude and Claude Code are trademarks of Anthropic, PBC, and nothing here is endorsed by or supported by Anthropic. The porting approach is stated next, and it is what makes this project different from a clone. The port follows the original file by file rather than reinventing the architecture, so a TypeScript component maps to a Rust component, a hook to a hook, and deliberate deviations are recorded in the source where they happen. That approach is also the reason the licence is what it is. The package is AGPL-3.0-only, which is the term that matters if you ever consider distributing a binary built from this code.

Why a fork of iocraft was necessary

Claude Code's terminal UI is TypeScript on React plus Ink, and CometixCode reproduces it in Rust on iocraft, which the README calls a React-style retained-mode TUI framework and the structural counterpart of Ink, with components, hooks and declarative elements. The build depends on CometixTUI, a fork of iocraft carrying the primitives this port needs. The README names them: row-level diffing, event propagation, SIGCONT self-healing, IME cursor handling, bracketed paste and grid layout. Those are exactly the features that a TUI framework needs and that are hard to retrofit, which tells you how deep the port goes. It is not a lookalike drawing in a terminal, it is a component model that has to behave the same way, and the fork exists because the upstream framework does not yet provide what the port requires.

Building it, and the one dependency on the host

The prerequisites are short: Rust 1.88 or newer with edition 2024, and nothing else, no system libraries and no pkg-config. The build and run commands are the standard Cargo pair:

cargo build --release
cargo run --release

The binary is named `cometix`. Cross compilation for Windows is documented as a target add plus a release build:

rustup target add x86_64-pc-windows-gnu
cargo build --release --target x86_64-pc-windows-gnu

A mingw-w64 toolchain has to be on `PATH` for that, because four dependencies compile C or assembly, `onig_sys`, `ring`, `tree-sitter` and `tree-sitter-bash`, and they link statically so the resulting executable needs no DLLs beside it. The one runtime dependency worth knowing about is ripgrep. File search shells out to `rg`, and the resolution order is a vendored binary next to the executable, then one in the source tree during development, then the host's `rg` on `PATH`. The binary is an external asset and is never compiled in, and a `/doctor` command reports which one is in use.

The test harness and why cargo test is not the gate

The testing section is unusually explicit, and the reason is a good one. `cargo test` is not a valid gate for this crate, because it runs the whole suite as threads in one process, and the codebase has process-wide state, environment variables and `OnceLock` caches, that leaks between tests as a result. The justfile instead runs the suite through `cargo-nextest`, which gives each test its own process:

just t <pattern>   # substring filter
just check         # type/borrow check only, links nothing

The justfile header shows the measurements behind the decision, with 530 failures for `cargo test --lib` against 23 for `cargo nextest run --lib` and 19 for `just test` on one commit with no test code changes. The comment explains that inside one process 164 files call `set_var` and 200 share a test environment lock, where one panic while holding it poisons the lock for every later test. Pinning the environment cannot fix tests stepping on each other, separate processes can, and the cost is roughly eight times the wall clock, which the file says is worth it for a result you can act on.

What is implemented and what is not

The README is blunt about the state of the port: it is a work in progress, large parts of the interactive loop, tool execution, permissions, MCP and slash commands are implemented, and other areas are partial. The Cargo.toml adds detail about the edges of that. There is a feature flag named `anthropic_internal`, described as an L1 replacement for the runtime gates that check the user type, with the default build being the external distribution and the flag compiling the Anthropic-internal capability profile, which cannot be enabled at runtime. There is a `voice_mode` flag that maps to a build-time guard in the original, with runtime voice streaming remaining unimplemented and the flag only enabling interface parity for read-only seams. And there is an `ultrathink` flag mapping to build-time transcript highlighting. So the gaps are not accidental, they are known, and in two cases they are compile-time choices you can turn on, which is the difference between a port that is incomplete and one that is deliberately scoped.

The Rust ports this project depends on

The acknowledgements section lists the projects whose work the port depends on, and it doubles as a map of the dependency surface. ClaudeCodeRev is the analysis work the port reads from, and the README says every behaviour was derived from studying Claude Code through it. CometixTUI is the TUI framework, the iocraft fork carrying the Ink parity primitives. marked-rs is a Rust port of `marked`, which Claude Code uses to parse Markdown, and anthropic-sdk-rs is a Rust port of `@anthropic-ai/sdk`, the API client. And nucleo, from the Helix editor project, is the fuzzy matcher behind file, command and agent completion. The Cargo.toml shows these appearing as git dependencies alongside the ordinary crates, with a comment that the fork and the three sibling checkouts are path dependencies locally and git dependencies in the public mirror, and that a sync script derives the mirror's manifest and lock. So the project is a small ecosystem of its own, and the build depends on a script keeping the two forms in step.

Where this is the wrong choice

The limits are structural and worth being direct about. First, the project says it is a work in progress, and the areas named as partial include permissions, which is the part that decides what an agent is allowed to do on your machine. A reimplementation of a tool that runs commands is not a neutral exercise, and the README's own framing, that it is built by reading the published CLI, is a description of reverse engineering by another name. Second, the licence. AGPL-3.0-only is the strongest copyleft in common use, and if you intend to run the binary in a company setting rather than on your own machine, that is a question worth settling before you build it. Third, the completeness of the model. The port maps components and hooks one for one, which is a good way to get behavioural parity, but it also means every upstream change is a change you have to port, and with an unofficial project there is no upstream to tell you when that happens. Fourth, the sponsor banner. A high availability AI API service is advertised in the README with a referral link, which is a commercial relationship in the project, and anyone evaluating the project should decide how they feel about that independently of the code. And fifth, the build environment: four C and assembly dependencies and a vendored ripgrep make the build less self-contained than a pure Rust crate would be, even though the README makes clear no system libraries or pkg-config are needed on the host.

Editorial conclusion

CometixCode fits someone who wants the Claude Code terminal experience as a static Rust binary they can cross compile and read, and who is willing to accept that the port is unfinished in the areas the README names. It is the wrong choice if you need a supported product, since it is explicitly unofficial and not affiliated with Anthropic, and the wrong choice if you want a complete implementation, because large parts of the interactive loop, permissions, MCP and slash commands are only partial. Before you rely on it, read the licence file, which is AGPL-3.0-only, and check the feature flags in Cargo.toml, since the Anthropic-internal capability profile and the voice and ultrathink behaviours are compile-time switches rather than runtime options. The last push was on 2026-10-14 and the package version is 0.2.0.

Frequently asked questions

Official sources

1. Haleclipse/CometixCode on GitHub
2. Issues
3. License: AGPL-3.0
4. README