code-mesh: Code Mesh Is Two Projects in One Repo

The Code Mesh project has been successfully implemented as a comprehensive Rust-based AI coding assistant with WASM support, achieving all EPIC targets and resolving all compilation errors.

ruvnet, Repository owner and project author · Issue #17, Code Mesh Implementation Complete

The README and the Code Tell Different Stories

The README for Code Mesh reads like release notes for a finished product. Multi-agent orchestration. Tool calling, end to end. Intelligent context windowing. A WebAssembly build for browser and Node users. Clone the repo, run code-mesh run "...", and you get something narrower: a single-turn chat client that talks to an LLM, saves the session, and prints the reply.

Here is the mismatch in one view.

The pattern is not sloppiness. The code that exists is careful. The interesting question is not why the README is ambitious. It is why the part that actually runs is so clean, and what that says about how the repo got here.

A Port, Not a Fork

Code Mesh is a Rust and WebAssembly port of OpenCode, the TypeScript terminal coding assistant. Port, not fork: the README credits OpenCode as the original implementation and frames Code Mesh as a reimplementation in a systems language with a WASM target. The project is MIT-licensed, sits at version 0.1.0, and is effectively the work of one visible contributor, ruvnet.

Porting is a reasonable bet. Rust buys a single static binary, predictable memory, and a path to the browser through WebAssembly. The catch is that a port inherits the original's scope while starting from zero on its implementation. That is the shape of the gap here.

What Actually Works

The core crate is the center of gravity, and it is well-factored. ProviderRegistry is constructed with an Arc of auth storage, so a registry consulted from several places shares one credential store instead of copying it. Providers are discovered in a clear sequence: from storage, then from environment variables, then initialized. The session layer sits behind a Storage trait, with a file-based default and SQLite behind a feature flag.

Two details earn real credit. The first is output discipline. When run finishes, the answer goes to stdout and the metadata goes to stderr.

println!("\n{}\n", result.content);      // answer to stdout
eprintln!("Session: {}", session.id);    // metadata to stderr

That split is the correct Unix pattern. You can pipe the answer into another tool and still read the session id on your terminal. The second detail is inline auth recovery. If the requested provider has no credentials, the CLI does not just fail. It prompts for login, re-runs discovery, and retries. A missing key becomes a login flow instead of a stack trace.

One Turn, Start to Finish

Follow a single invocation of code-mesh run "explain this error" and the actual data flow becomes visible, along with two trap doors.

The first trap door is ordering. The user message is written to disk before the provider is even resolved. If auth fails or the model call errors, the message is already persisted with no reply beside it. Run a few failed prompts and the session fills with orphaned user turns.

The second is history replay. The code maps every stored message into the provider's message type and sends the whole list. There is no windowing, no truncation, no token budget. The README advertises intelligent context windowing. The code sends the full transcript every time.

The Claims That Outrun the Code

Multi-agent orchestration is the headline claim. The agent/, planner/, and memory/ modules exist in the core crate, but the run path never invokes them. Tool calling has the same shape: tools are never passed to the model, and tool_calls in the response are never inspected. WebAssembly is a workspace exclusion, not a build target: the code-mesh-wasm crate is left out of the root Cargo.toml. The TUI crate is complete enough to compile, but mod tui is commented out in main.rs with a TODO.

The README also documents commands the CLI does not have. code-mesh sessions list has no subcommand behind it. --mode beast is a free-form string the run path never reads.

Issue #17 declares the implementation complete and all targets met. It sits next to a CLI that does not call a tool.

The Fingerprints

Look at how the repo was built and a second story appears. #![allow(warnings)] sits at the top of both main.rs and lib.rs, suppressing every compiler warning in the two entry points. The verbosity mapping has match arms for "warn" and "error" that can never be reached, because the string is always info, debug, or trace. Status documents in docs/legacy/ are titled COMPLETE.

• allow(warnings) at the top of both entry-point files, silencing the compiler wholesale.
• Unreachable match arms for warn and error that no input can trigger.
• Committed agent-tooling state sitting beside the source it was used to write.
• Status documents named COMPLETE, recording a finish line that tests do not measure.

None of this is damning on its own. Read together, it is a recognizable signature: a codebase produced with heavy agent assistance, where generated scaffolding is committed alongside the code and the finish line is declared in a document rather than measured in tests. This is worth understanding without snark, because it is about to be everywhere.

Where Code Mesh Sits

Two facts stand out. Code Mesh is the only project in this list written in Rust, and it is the only one whose README describes a more finished product than the one that exists.

A Skeleton Worth Watching

The load-bearing walls are sound. The provider abstraction, the session trait, and the stdout/stderr split are the decisions you want to get right early, and they are right. What is missing is the shell: the agent loop, the tool dispatch, the context window.

If that shell gets built, the Rust and WebAssembly angle is a real differentiator against a field of TypeScript agents. If it does not, the repo becomes a case study in the distance between a README and a binary. Either way, it is worth a bookmark.