Persistent sessions
An agent may spend hours working on a task. I do not want that work to depend on keeping a desktop window open. xNaut uses Zellij, a terminal session manager, to keep supported terminal sessions running independently of the client. You can close the window and reconnect to the session while its host and processes remain running.
A persistent session does not automatically recover every failed agent process. Treat session persistence, process recovery and task retry as separate concerns.
Worktrees: a working directory for each task
A Git worktree is another checkout of the same repository in a separate directory. It has its own checked-out files and staging area while sharing the repository history. You can keep one branch open in your main directory and work on another branch alongside it, without repeatedly switching branches or stashing unfinished changes.
For example, one agent can fix a login bug while another updates the documentation. Give each a worktree and a branch, and their edits stay in separate directories. You can inspect and test each change before merging it. They can still change the same lines on their respective branches, so merge conflicts remain possible.
In xNaut, the worktree manager lists, creates and removes these checkouts. Starting a task from a repository issue can create a worktree for that ticket and place its context alongside the code. Normal removal refuses a worktree with uncommitted or untracked files, so unfinished work is not silently discarded.
A worktree separates files, not permissions. An agent running locally may still have access to your credentials, network and other directories. That is where a sandbox becomes useful.
Sandboxes: run the code on another machine
Installing dependencies, executing generated scripts and testing an application all run code. A virtual-machine sandbox gives that work a separate operating system and filesystem, away from your everyday development machine. You choose what code and credentials to send into it.
Worktrees and sandboxes work together. The worktree holds the changes for a task; the sandbox provides a place to build and test them. The results need to come back with enough context to identify what ran and which code it tested. A passing test against yesterday's checkout says little about today's change.
A sandbox still needs deliberate access settings. Credentials copied into it and services exposed over the network remain your responsibility. Isolation does not make arbitrary code trustworthy.
Use the exe.dev integration
xNaut integrates with exe.dev so development and testing can run in a remote VM. Start by creating an exe.dev account, registering your SSH key and preparing a VM with the tools your project needs. Connect that environment to xNaut before sending work to it. An account alone does not configure repository access or install your toolchain.
The documented verification integration selects exe.dev per repository through .xnaut/verify.json. It synchronises the repository to the configured VM and runs the install, build and test commands over SSH. The run produces a record and attaches its results to the ticket for review.
This setup uses a persistent VM. Installed tools and build caches can survive between runs, which avoids starting every check from an empty machine. That also means you should distinguish a repeat run in an existing environment from a test in a freshly created sandbox.
NautLoop: sandboxes with an expiry time
I am also developing NautLoop, our own sandbox system for this kind of work. Its GitVM-based workflow gives a project a temporary virtual machine with a defined lifetime. TTL means time to live: the lease determines how long the sandbox remains available before the system reclaims it.
The GitVM workflow creates a sandbox for a working directory, synchronises the code into its /workspace directory and runs commands there. A configured exposed port gives the running application a URL, so you can inspect or test it while the sandbox is active. A worktree for each task lets those tasks use separate sandbox environments.
The lifecycle matters as much as creating the machine. Copy back the files and results you want to keep before stopping the sandbox or letting its lease expire. Teardown destroys its workspace. Your repository remains the lasting record of the code, not the temporary VM.
NautLoop is still in development. It addresses the same need for remote development and testing, with an emphasis on environments that expire after the work. Do not assume it has the same setup or availability as exe.dev.
Bring the result back to the ticket
The verification plan tells xNaut how to install, build and test the project. An explicit .xnaut/verify.json supplies those commands; supported Node projects can also use detected package scripts. Recording the commands, exit codes and output makes a failed run something you can investigate rather than a vague failure message.
A successful run returns the work for review. It does not establish that the tests cover every requirement or that the application behaves correctly in production. Check the tested revision, inspect the changes and decide whether the evidence answers the ticket before closing it.
Record the work behind a timesheet
A client once questioned whether I had spent the time I reported on a project. I already had the work-recording tool I had built, so I could go back to the activity behind my timesheet. That experience is an important part of why work logging belongs in xNaut.
Start a work log for a client and project. While recording is active, xNaut records captured terminal commands with their timestamps and working directories. Stop the session to finalise it and produce a report with the session times and recorded actions. It gives you something concrete to discuss alongside the work delivered.
The entries form a hash chain: each entry includes a fingerprint of the preceding entry. When the session ends, xNaut combines the entry hashes into a Merkle tree. Its root is a single fingerprint of those entries, which can be compared with a previously retained root to detect changes to the covered fields.
The log supports a timesheet; it does not measure every minute of human effort. Time between commands may include thinking, a meeting, a long build or a break. Work outside the captured terminals needs its own explanation. Review the commands and paths before sharing a report, because they may contain client information.
Sign a record so someone else can check it
A locally calculated hash is not a digital signature. Someone who controls a log can rewrite it and calculate new hashes. Keeping a trusted copy of the root helps detect later changes, but independent verification needs a record the reviewer can trust.
xNaut also has a separate execution-evidence system for captured agent actions. With the Securosys integration configured, it groups records into Merkle-tree checkpoints and signs those checkpoints using a key held in a hardware security module. This is separate from the basic Work Log report; starting a work log does not automatically give it an HSM signature.
An exported evidence bundle can be checked offline using a separately trusted public key. The verifier checks the record hashes, chains, Merkle roots and checkpoint signatures. A reviewer can check whether the covered records match the signed checkpoint without needing access to the signing key. The documented checkpoint, export and verification tools run from the command line.
Signing establishes the integrity of the covered record relative to that key. It does not independently establish that every event was captured, that a timestamp reflects an independently verified clock, or that all elapsed time was billable. The value is a record that can be examined and checked, alongside the code, test results and project history.