Fusion: five ways to install one command, a bearer token in the dashboard URL, and a test gate made of sixteen prohibitions

Five documented installs reach the same two binaries

The quick start offers five ways in, and they are not variants of one another. The shortest needs nothing installed:

npx runfusion.ai

Subcommands forward through that same entry point, and the readme notes the fully qualified form for when you want to be explicit. A second path pipes a remote script into a shell:

curl -fsSL https://runfusion.ai/install.sh | sh
fusion dashboard

which auto-selects Homebrew and falls back to npm. A third is a Homebrew formula from a tap the installer adds for you, with a documented recovery when the short name fails on a newer Homebrew:

brew install runfusion/fusion/fusion
fusion dashboard            # or: fn dashboard

The readme says that on Homebrew 6.0 and later the installer trusts only the Fusion formula, and that if you have already tapped and see an untrusted tap error, you run a trust command naming the formula and then install again. The fourth is a global npm install of the scoped package, and the fifth is running the dashboard straight from a clone. Two binary names, one long and one two letters, and two npm names: the unprefixed one used for npx and the scoped one that is the real package.

The dashboard token arrives in the URL query string

After the dashboard starts, the terminal prints a link, and the readme explains exactly what is in it:

http://localhost:4040/?token=fn_...

The browser captures that token into local storage on the first visit and reuses it afterwards. On the server side, the token is written into a settings file in the user's home directory on the first authenticated run and reused on later starts, unless you override it with a flag or one of two environment variables, or turn authentication off entirely with a no-auth flag. The design is convenient and the delivery mechanism is the weak point. A token in a query string is a token that lands in shell history, in browser history, in any proxy or server access log between you and the machine, and in the referrer header of anything the page loads. It is also a bearer credential with no scope, which the readme's own reset and revocation options are there to manage. If you expose that port beyond loopback, replace the mechanism rather than the password.

The test gate is sixteen scripts phrased as prohibitions

Before any test runs, sixteen custom scripts execute, and their names are the clearest documentation of this project's history in the whole repository. Among them: nothing may be backgrounded with nohup, nothing may read the database through the direct getter, nothing may kill the process on the dashboard port, nothing may read dashboard state through a working directory relative path, nothing may import core modules that only exist in the Node runtime into the dashboard, nothing may bump a test timeout to make a test pass, and nothing may assert anything in a comment. Others are positive: the pre-rebase step must be inert, the capacity pool identifier must be right, CLI runtime routing must hold, the project versions must be pinned, the workspace package graph must be consistent, the changeset format must be valid, routes must stay modular and the runtime skill loader must not drift. Every one of those names is a scar. A test suite that refuses to start until its own list of past mistakes is re-checked is unusual, and more useful than a page of conventions.

Dated editorial directives sit inside the readme and the Dockerfile

Both files carry comments that are instructions to a future maintainer rather than documentation for a reader, and both are stamped with a date and a machine readable prefix. In the readme, a comment above the feature table says the file must surface PostgreSQL as the default storage and the recently shipped operator surfaces so that the public front door matches the shipped product, that the legacy SQLite path is a one time migration input only, and that the feature claims below should stay grounded in release notes and linked product documentation rather than fresh demo assets. In the Dockerfile, a similar comment explains why a specific copy list exists and what breaks if it drifts. These are dated change records embedded in the sources, which is a useful convention and a small hazard: they instruct an agent or a maintainer about what to change, and they sit in the rendered file for every reader to trip over. Nothing in the repository documents the convention, so it is discoverable only by noticing the pattern.

Adding a workspace package means editing the Dockerfile

The image build copies workspace manifests one at a time before it runs a frozen install, and the comment above that block explains the constraint: every selected workspace manifest must be copied before the frozen install, or the package manager omits its dependencies and the later full workspace image build can fail. The list it produces is long, covering packages for the command line tool, an alias package, the core, the dashboard, a desktop shell, a mobile shell, an engine, internationalisation, and two provider specific integrations, plus four example plugins under a plugins directory. So adding a package to the workspace means remembering to add a line to the build file, and the comment says the list is derived from the workspace configuration file that sits next to it. Nothing enforces the correspondence; the same dated note that explains the problem is the only thing standing between a new package and a broken image.

Storage moved to an embedded database and the old file format is a migration input

The feature table states the current design plainly: the runtime metadata uses zero-configuration embedded PostgreSQL on the local machine, and legacy SQLite files are one-time migration inputs only. It then directs anyone running several projects or several nodes at a shared external database, with a separate document for the storage details and another for the multi-node setup. This is the kind of change that is invisible until you read for it, and it has a practical edge. A project that reaches for embedded database mode on a machine with several checkouts will either get one store per project or a shared one, and the difference determines whether a dashboard can see work from another checkout. The readme's own comment explains that the decision was made partly so the public documentation would match the shipped product, which is a candid admission that the documentation had been describing the older behaviour.

Four oversight levels, and two actions always stop for a human

The part of this design that answers the autonomy question is specific rather than a slogan. Oversight is set per task or per workflow and takes one of four values: off, observe, steer, or autonomous. Each step names how closely a planner overseer watches and intervenes. Then there is the exception, stated in the same sentence as the setting: merging, pull request actions and destructive actions always require explicit human confirmation. So the highest level does not mean unsupervised, it means supervised by rules rather than by a person at each step. Two other workflow surfaces exist around that. Built-in workflows cover coding, quick fixes, review-heavy work, stepwise execution, a compound engineering workflow that is gated behind a plugin, and fragments for the pull request lifecycle, and a workflow editor lets you author your own. And each task runs in its own branch and worktree named after the task, so parallel tasks do not collide, with optional delegation to an external worktrunk backend.

Six translations, a changelog archive, and a beta shipping every other day

The repository layout says a lot about the project's stage. The root holds six translations of the readme, in Spanish, French, Korean, Brazilian Portuguese, Simplified Chinese and Traditional Chinese, which means every documentation change lands in seven files or drifts. Alongside them sit a mobile guide, a concepts document, a strategy document, a roadmap, a releasing guide, an agent instruction file, another instruction file, a changelog, and a separate changelog archive, so history is split across two files. There is also an audit directory, a reports directory, a screenshots directory, a demo directory with a seed script and a simulation script, and a plugins directory with four example plugins. The release cadence tells the rest of the story: the three most recent tags are all the same beta line, at 0.78.0 beta 5, beta 6 and beta 7, published on the 20th, 23rd and 25th of September 2026, with the workspace manifest carrying the same version and a lock on the package manager that the Docker build also pins.

Editorial conclusion

Fusion fits a team that already trusts an agent with a scoped change and wants the plan, the diff and the review trail kept together, since the design is built around reviewability rather than autonomy. It does not fit someone who wants a coding assistant in an editor, because the unit of work here is a task with a branch. Four things to check before the first run. How you will install it, since five documented paths reach the same two binaries and each one has its own trust step. Where the dashboard token travels, because a credential passed in a URL query string ends up in shell history and browser history, and there is a flag that turns authentication off altogether. What the storage layer does on your machine, because the default is an embedded database instance and the older file based one is now only a migration input. And how far the agent may go, because there is a four level oversight setting and two categories of action, merging and destructive work, that always stop for a human.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes