What is xNaut and who is it for?

Too many windows

At the beginning of 2026, I sat down and asked what xNaut could become. I already had a CLI that served my own work, but my development setup still meant moving between too many windows. I wanted most of those tools in one workspace.

I work mainly in the shell. I had also spent a lot of time in Zed and tried several coding-agent tools. Some suited parts of my workflow; others became frustrating in daily use. I made a list of the terminal features I wanted, then did the same for coding agents.

That list shaped xNaut. I borrowed ideas I liked in other tools and brought them together around the way I work. I still use other applications, and sometimes two windows are faster. The aim was to reduce the switching that got in the way.

What is xNaut?

xNaut brings project terminals, documents, Git worktrees and coding agents into one desktop application. You can follow running work, inspect changes and keep the information needed to review a project beside its execution.

For work coordinated through tickets, NautBot assigns tasks and tracks their results. An implementation agent makes the changes in a separate worktree. A verification agent checks the code and runs tests before the result returns for human review. Several tickets can proceed in parallel.

NautFlow and the full development lifecycle

As a developer, I wanted xNaut to support the whole software development lifecycle. Writing code is one part of that work. You also need to establish whether the product is worth building, define its requirements and decide how to test the result.

In 2024, I built a tool to help evaluate a product idea and develop its business case. I also experimented with a build loop that took instructions from a Markdown file, worked through the resulting tickets and checked its work as it went. Those projects were the starting point for NautFlow.

I tried several tools and workflows before bringing my own approach into xNaut. NautFlow connects the business case, requirements, architecture and tickets with implementation, testing and release. The intended scope includes the product website as well as the application.

1. 01Business case
2. 02Requirements
3. 03Architecture
4. 04Tickets
5. 05Build
6. 06Test and review
7. 07Release

Answering the questions before building

NautFlow asks questions at each stage, checks the answers and returns to points that need clarification. In the guided process, you steer the work through those conversations. Expert mode gives you more control over how the stages are defined.

This takes time. In my own use, answering questions can take one or two hours before the build starts, and the work that follows can run for many hours. The questions help establish what the application should do and how we will know it works.

I call this speed coding. The goal is to let someone develop an idea through defined stages without having to know every technical step in advance. xNaut is where I am bringing that process together. Technical decisions and finished work still need review.

Getting an agent to finish a ticket

The harder problem has been getting agents to carry out tasks reliably. In my experience, a model needs more than a goal and permission to run. It needs access limits, a controlled execution environment and checks on what it produces. Much of my work on xNaut has gone into that surrounding process.

The workflow I want starts with a ticket. The agent examines it, asks questions and develops a plan for review. After approval, it implements the change, builds and tests it in a sandbox, and submits the result for verification. It then commits and pushes the changes, prepares a pull request and reports what it did, with the checks available for inspection.

I consider that workflow about 90% of the way to where I want it. That is my assessment of its development, not a measured success rate for agent runs. It works, but making the whole process dependable is still the work in progress.

How the parts fit together

The desktop window brings terminals, project files, documents and agent controls together. Underneath it, a Rust backend manages the terminal processes and provides access to files, Git and configured services. Tauri connects the window to that backend.

A terminal agent runs as a process in its session. The built-in agent chat connects through the configured model providers. Remote execution and sandbox integrations provide other places to run work, while the project keeps its code and documents in files and Git repositories.

Checking on work from a phone

I also liked the idea of following running work from a phone. That led me to build a mobile companion for xNaut, with session visibility and access to coding-agent activity.

The mobile extension is not released yet. It connects a phone browser to a bridge in the desktop application.

For developers working with agents

If your work is spread across terminal windows, agent conversations and Git branches, xNaut gives you a place to manage it together. You can see which agent is working on which task and inspect the changes it produces.

The open-source edition is for individual use. It is aimed at people who already work with development tools and want to manage their coding agents alongside their projects.

For development teams and technical leads

Teams need to know who owns a task, which revision was tested and who approves the result. xNaut connects tickets to implementation, verification and final review so those decisions can be made from the work recorded.

The Enterprise edition uses its own registry to connect xNaut clients for team collaboration. That shared workflow has a separate scope and terms from the individual open-source edition.

What to check before adopting it

xNaut is early-stage. Check that your agents, model connections and execution environments are supported. Local models are an option where compatible; a model connection alone does not establish that a particular agent workflow will work.

Try a representative ticket and review its code changes, test results and handoff. The person reviewing the work remains responsible for deciding whether to close the ticket. The next chapter explains the sessions, worktrees and optional signed records behind that process.