Nanocode-CLI

Coding agents that touch real files have a basic reliability problem: they read a file, plan an edit, and by the time they write, something else has already changed that line. nanocode addresses this with line-and-hash anchors — every edit specifies not just a line number but a hash of the content at that line, and the tool refuses to apply the edit if the hash no longer matches. The agent runs as a multi-turn loop: it reads files, builds a line-numbered view of what’s relevant, executes shell commands, and streams responses while accepting follow-up input mid-run without dropping the current tool flow.

The differentiating design choice is the file-state model. Rather than passing raw file dumps into the prompt, nanocode maintains a current, line-numbered view of only the files that have been read or edited in the session. Tool output is bounded in the prompt to prevent context blowout, but raw results stay recallable. The vendor describes this as a ‘file-state brain’ — the agent always knows the current shape of the files it is working on, not the shape they were in when the session started.

The tool is a single Python file under BSD-3-Clause with no commercial tier. Configuration is TOML-based, and the LLM provider is entirely user-configured — you can point it at a local model or a remote API without any vendor lock-in, which means data never leaves your infrastructure unless you choose a remote endpoint. The project self-describes as pre-1.0 software; the docs explicitly warn that commands, configuration, and tool behavior are subject to change before a stable release. Teams that need stability guarantees, IDE integration, a visual workflow canvas, or a plugin ecosystem will find none of those here. Teams that want to read and understand every line of the agent loop before deploying it in a restricted or sensitive environment will find that the entire system fits in one file.