Carbon Code

The materials show approval gates for commands, edits, plan checkpoints, and out-of-sandbox path access in ordinary modes; chat mode has no filesystem or shell tools, and initialization protects existing rule files by default. However, an explicit yolo mode automatically permits commands, background processes, and path access, and no complete permission matrix is supplied. Default diagnostic collection, excluded content, the offline queue, and opt-out controls are described, while key storage and non-commit guidance are documented; file permissions, encryption at rest, and rotation are not shown. CI runs scheduled CodeQL with narrow permissions and dependencies are declared, but no lockfile, dependency audit, or vulnerability-response evidence is included. External effects are approval-controlled, yet no general edit recovery, command undo, or rollback design is demonstrated. MIT and third-party notice locations, author, and repository metadata are present, but the publisher is unverified and the relationship between “Reasonix Contributors” in LICENSE and Yapie0 in package metadata is unexplained.

The README, package metadata, CI, and supplied tests are broadly consistent about command names, Node.js requirements, approval behavior, MCP loading, and session records. Dependencies are declared and npm ci feeds verification on Ubuntu and Windows, but the evidence does not establish comprehensive fallback behavior when model services, npm packages, or MCP servers are unavailable. MCP initialization and parse failures are logged, failed clients are closed, processing continues, and a setup hint is tested. Only a narrow set of failure paths is covered, so actionable handling for network, authentication, write, and shell failures is not established.

The target audience and personal-development workflow are explicit, with distinct entry points for installation, chat, one-shot tasks, project initialization, health checks, and updates, fully supporting the audience-and-scenarios criterion. Tool-free chat, security scope, third-party MCP exclusions, and edit modes define meaningful boundaries, but yolo risk and ACP/MCP options are not fully documented in the main README. Command triggers are reasonably precise and tests cover MCP prefixes and disabled servers, although some tested commands and options lack matching user-facing documentation. Node.js 22 requirements, a PowerShell workaround, dual-platform CI, environment variables, and configuration paths provide thorough environment-fit evidence.

The README sensibly organizes installation, commands, configuration, diagnostics, licensing, and links to further guidance, but the supplied files do not provide complete navigation or a comprehensive reference. Installation covers global, one-off, and Windows usage and earns full marks. The carboncode/ccode names are stable and the avoidance of cc is explained, though lingering Reasonix names reduce consistency. There are useful examples and one common PowerShell remedy, but no systematic FAQ. Limitations are only scattered through scope and mode descriptions rather than documented comprehensively. The MIT text agrees with package metadata and third-party license locations are named, justifying full license credit. A 0.2.14 version is present, but no changelog or compatibility policy is shown. Maintenance routing is limited to repository issues and a vague instruction to contact the owner privately, without a named team, response policy, or verified identity.

The command design, plan approvals, validation workflow, concise session trail, and transcript tests covering tool arguments, usage, and cost indicate ordinarily usable development output. Automatic tasks, MCP, multi-agent, and provider support could add material value, and some mechanisms are tested, but the supplied tests focus on ACP/MCP and approval edge cases rather than the complete autonomous-development proposition. Claims of more than 90% token savings and capability near Claude Sonnet 4.6 have no benchmark, methodology, dataset, or results, so cost-benefit evidence is thin.

Some operational claims trace to package scripts, CI, and tests, including cross-platform verification, non-fatal MCP failures, approval modes, and transcript fields. Core marketing claims have no benchmark or experimental record, limiting traceability. The README, package metadata, workflows, security policy, and tests corroborate several facts, supporting an ordinary cross-source score. The material does not clearly distinguish tested facts, design intent, and speculative comparisons—especially the “first,” “over 90%,” and “approaching Sonnet 4.6” claims—so fact/inference separation remains weak.