dexto's root manifest reads 1.1.3 while the published packages are 1.13.3

The root manifest reads 1.1.3 and the published packages read 1.13.3

Version tracking in this monorepo has two sources that do not agree, and the gap is a digit transposition rather than a scheme. The root package is private, named for the monorepo rather than the product, and declares version 1.1.3. The three most recent releases are the main package, the terminal UI package, and a tools package, all at 1.13.3, published within about half a minute of each other. For a private root that is a normal pattern, since it never reaches a registry, but 1.1.3 against 1.13.3 is exactly the shape of string a person misreads at a glance, and the root manifest is the file most likely to be opened first. The release batch itself is the more interesting signal: three packages, one version, one publish.

Two build scripts are byte-identical under different names

The root manifest carries a long list of targeted build scripts, each filtering the task runner down to one package, and two pairs among them are exact duplicates. One script runs a typecheck and then a build, and a second script with a stricter-sounding name runs the same two commands in the same order. Elsewhere, the script that builds the web interface and the one labelled as its development variant are the same filter string. Neither duplication breaks anything, since either name works, but they are the kind of artefact that appears when a name is added for discoverability and the body is copied rather than renamed. A third route for the same package does something different: it deletes the local modules directory, reinstalls inside that package with the package manager scoped to it, and builds there, bypassing the task runner entirely.

The engines block still demands npm in a pnpm-pinned repository

The root manifest declares two engine constraints: Node at 20.0.0 or newer, and npm at 8.3.0 or newer. It also pins a package manager field to a specific pnpm release. The npm constraint is a leftover from an earlier layout, because nothing in the documented workflow installs with npm. Every install path in the readme goes through pnpm:

curl -fsSL https://dexto.ai/install | bash

The source route is a clone followed by two pnpm commands, one of which installs the CLI package specifically, and the container build installs pnpm globally at a pinned version before running a frozen-lockfile install. The comment next to that container line explains the choice as avoiding signature verification problems with the built-in package manager shim, which is a real class of failure and a good reason to install the tool explicitly.

The compose file is still the stock scaffold

The container story is well built and the orchestration story is not started. The image is a two-stage Alpine build with a pinned Node version, a build toolchain for native modules, a pruned production install, Chromium installed for the browser tools, and a non-root user with its own group and a data directory it owns. The compose file beside it, by contrast, is the unmodified example that ships with a new Compose project: a comment thanking the reference guide, a link to a sample collection, one service built from the Dockerfile, an environment file, production mode, and a single published port. Below that sit roughly twenty-five commented lines describing a PostgreSQL service, a persistent volume, and a password secret, with a note that you must create the password file yourself before running it up.

Every line of the environment example is commented out

The example environment file is a list of settings that are all disabled, and its header explains why: secrets are written into a per-user file the first time the CLI runs, and this file is only for overriding runtime behaviour locally. The disabled entries are the interesting part, because they name the surface area. There are two logging switches, a Discord bot token with its own rate limit and interval, a Telegram bot token with an inline query concurrency setting, and a four-value port and URL block separating an API port from a frontend port. The compose file maps only the API port and reads the environment file that ships empty. So the container path starts with no keys, no rate limits, and a frontend the compose file never publishes.

Tool approvals are remembered per session, not per project

Human-in-the-loop control is configured in the agent's YAML file, with a permission mode that requires approval for each tool call and an alternative trust mode meant for local development. Alongside it is an allowlist naming individual tools, written in a namespaced form that pairs the server and the operation. The behaviour that deserves a second read is the last line of that section: agents remember which tools you have approved per session. Approvals therefore do not accumulate into a durable allowlist, so a fresh session starts from the manual mode again. That is a defensible default, since a tool approved once for a read is not automatically approved for a write a week later, but it means a repeated workflow re-confirms itself at every restart rather than converging. The same applies to the sub-agent configuration, where a spawner names which agents are allowed, caps concurrency at five, and sets a default timeout of five minutes in milliseconds, all of which live in the agent config rather than in a global policy file.

The integration heading claims 30+ tools and shows two servers

The Model Context Protocol section is titled as an integration with more than thirty tools, and the configuration example that follows defines two servers. One launches a filesystem server over standard input and output with a working directory argument, and the other launches a browser automation server from a different vendor's package. Five services are named in the surrounding prose, which are enough to show that the claim is about an ecosystem rather than about what ships here, but a reader counting examples will not reach thirty and should not think they are missing configuration. Servers can also be browsed and added from a store in the web interface, or through a slash command in the terminal, which is where the larger catalogue actually lives. The one built-in sub-agent is a read-only codebase explorer, which is what the coding agent uses to delegate exploration before editing anything.

The repository ships instructions for three assistants and an agent

The root directory is crowded with the tooling of assisted development, which is a slightly odd fit for a project whose whole purpose is to be one. There are configuration directories for three assistants, and top-level instruction files for three more: one general, one for a specific terminal assistant, and one for a third. There is also a husky directory for commit hooks, a prettier configuration, custom lint rules beside the lint configuration, two test configurations with a setup file, a task runner configuration, and a changeset directory for versioning alongside a versioning document. The example directory collects fourteen starters, including agent delegation, a research agent, chat integrations for two platforms, a memory server, a resources server, skills, and an integration with a different agent framework entirely.

Editorial conclusion

dexto suits a team that wants an agent layer they can describe in YAML rather than code, with the model swappable mid-conversation and tool use gated behind explicit approval. It does not suit anyone who wants the approval list to persist, since permissions are remembered per session, or anyone who expects a finished container setup, because the compose file is still the stock scaffold. Before deploying, read the version string question for yourself, since the private root and the published packages disagree, and expect to set the environment by hand because every line in the shipped example is commented out.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. truffle-ai/dexto on GitHub