ACFS, a one-liner VPS bootstrapper, and what it does to your sudo

What the one-liner actually installs

The quick install is a single command that fetches a script and pipes it into a shell:

{ acfs_installer="$(curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/agentic_coding_flywheel_setup/main/install.sh")" || acfs_installer="$(curl -fsSL "https://cdn.jsdelivr.net/gh/Dicklesworthstone/agentic_coding_flywheel_setup@main/install.sh")"; } && printf '%s\n' "$acfs_installer" | bash -s -- --yes --mode vibe

Two flags do most of the work. `--yes` removes the interactive confirmation, and `--mode vibe` selects a preset the README describes as pre-configured for maximum velocity, with passwordless sudo, what it calls dangerous agent flags enabled, and an optimised shell environment.

The inventory is broad. The README counts thirty-odd tools installed by the one-liner and twenty-odd more developer tools beyond the named highlights. The named highlights are a modern shell with zsh, oh-my-zsh and powerlevel10k; the language runtimes including bun, uv for Python, Rust and Go; agent coordination tools identified as NTM, MCP Agent Mail and SLB; and cloud CLIs for Vault, Wrangler, Supabase and Vercel.

The audience is stated three times in three different registers, and the register tells you what to expect. For beginners, the project pairs the script with a wizard website that walks someone from installing a terminal, through generating SSH keys, through renting a VPS from a provider such as OVH or Contabo, to running the installer and reconnecting with key-based access. For developers, it is a one-liner for any fresh Ubuntu or Arch-based machine. For teams, it is a reproducible and idempotent setup intended to make every member's environment identical.

The idempotency claim is specific and testable. The README says that if the installer is interrupted you simply re-run it, and that it resumes from the last completed phase without prompting. For a thirty-step provisioning script, that is the difference between a tool you retry and a tool you abandon, and it is the property most worth verifying on a scratch machine before you trust it with anything.

The checksum ledger, and the failure it is actually designed for

The repository contains a `checksums.yaml` at its top level, and the README documents a specific error message that comes out of it: `INTEGRITY: <file> missing`, raised when the installer's bootstrap extraction list does not match the current checksum ledger.

That message is explained in the README's note about download ordering, and the explanation is worth reading carefully because it tells you what the ledger is for. The primary source is `raw.githubusercontent.com`, with jsDelivr as a fallback, and the author states the order is deliberate: jsDelivr caches a mutable `@main` reference, so it can serve an installer that is hours or days behind the repository. When that happens, the stale installer's extraction list does not match the current ledger, and the install fails with the integrity error. The README describes that failure as looking like a repository defect when it is purely a CDN cache artefact.

So the ledger's job is narrower than it first appears. It detects a mismatch between the installer you received and the file list that installer expects, which covers a stale mirror, a truncated download, and a partially updated branch. It does not, on the evidence available, protect you from a malicious change to the upstream branch, because `install.sh` and `checksums.yaml` are both fetched from that same mutable reference. A compromise at the source would ship a matching pair.

That is not a criticism of the mechanism. A ledger that catches stale mirrors and corrupt transfers is a real improvement over piping whatever the CDN returns, and the failure mode it produces is a hard stop rather than a corrupted install. It is a distinction worth holding, though, because integrity checking and trust are different properties, and only the second one is unaddressed. The README's own answer to the second is the pinning guidance: for production environments it recommends a tagged release or a specific commit rather than a branch reference.

The other detail in that note is a small piece of good engineering. Each download is buffered before execution, so a failed request cannot concatenate a partial installer with the fallback response. That is the kind of detail that only appears in a script that has been debugged on a flaky network.

Pinning: what the README recommends for production, and what the default does

The README separates the beginner path from the production path, and the difference is one URL and one flag.

The default quick install references `main`, so every run gets whatever is at the head of the branch at that moment. For production the recommendation is a tagged release, and the example given is v0.9.0:

# Preferred: use a tagged release (e.g., v0.9.0)
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/agentic_coding_flywheel_setup/v0.9.0/install.sh" | bash -s -- --yes --mode vibe --ref v0.9.0

The `--ref` flag is the part that is easy to miss, and the README explains it: passing it ensures that all fetched scripts use the same version. Without it, you have pinned the entry script and left every library, module and helper it downloads to resolve against the branch, which reintroduces exactly the drift the pinning was meant to remove. The alternative form, pinning to a specific commit SHA, is given as well.

This is a well-constructed recommendation and it arrives in a place a reader is likely to see it, in a callout for production environments. The gap is that the quick install above it does not mention any of this, and a beginner following the wizard will run the unpinned version because that is the command at the top of the page. Given that the project explicitly targets people who have never used SSH before, that ordering is a real design choice about who the default is for.

The supported platforms are narrower than the Vision diagram suggests. The badge says Ubuntu 22.04 or later, or Arch and Omarchy, while the architecture diagram shows Ubuntu 25.10 on the VPS. Both can be true, since the diagram illustrates a particular setup, but anyone on Debian or Fedora should confirm before starting, and the repository description itself says Ubuntu VPS.

Vibe mode, passwordless sudo, and who the defaults are written for

The security posture of this project is best understood as a deliberate choice rather than an oversight, and the README is direct about what the default mode does.

Vibe mode is described as pre-configured for maximum velocity, with passwordless sudo, dangerous agent flags enabled, and an optimised shell environment. Take those three together and you have a machine where an AI coding agent can install software, change system configuration and reconfigure your shell without a human confirming anything. That combination is coherent for the stated use case: a fresh VPS rented for the purpose, holding nothing, whose entire job is to be driven by an agent. It is a poor fit for anything else.

The wizard flow reinforces the framing. The beginner path is renting a VPS, connecting with a password for the initial setup, running the installer, and then reconnecting with the SSH key the installer configured. The machine is disposable by design, and the passwordless sudo is there so an agent that needs to install a package does not stall waiting for a human who may be asleep.

What the README does not provide is a mode description for anything more cautious. `--mode vibe` is named in both the quick install and the pinning example, and no other mode is shown, so the conservative path appears to be editing the defaults or reading the installer's options before running it. If your threat model includes a prompt injection arriving through a repository the agent reads, this is worth pausing on, because an agent with unattended root on a machine that has your credentials is a different proposition from an agent with a shell.

The idempotency and the resumability are the mitigations that do exist, and they are genuine: a provisioning script you can interrupt and re-run is one you will actually use twice rather than abandon. Neither addresses the privilege question.

One more environment variable is worth knowing about before you install anything. The root `package.json` in this repository declares a `trustedDependencies` list containing `sharp` and `unrs-resolver`, which is the allowlist of packages permitted to run install scripts under Bun. Everything else is denied. That is a stricter posture than most JavaScript projects take, and it is a reasonable signal about how the author thinks about supply chain, even though it applies to this repository's own tooling rather than to the installed agents.

acfs.manifest.yaml as the source of truth, and the seam with install.sh

The architecture section is short and it is the most interesting part of the README for anyone thinking about maintaining this.

ACFS centres its tool inventory and its generated module metadata on the manifest. From that, generated installer libraries and the doctor checks are derived. The README is explicit about the exception: `install.sh` and several orchestration libraries retain explicit authored handoffs rather than being generated. And drift checks cover the seam between those two layers.

That is a codegen pipeline with an honest description of its own limits, and the admission is the valuable part. Projects that generate most of their installer from a manifest tend to either pretend the generation is total, which makes the generated code impossible to debug, or leave the generated layer unmentioned, which makes the authored patches look arbitrary. ACFS names both layers and says a check exists between them.

The manifest is also what produces the agent roster, and you can see the mechanism in the README itself. A block marked as generated, with a comment recording its source as `acfs.manifest.yaml`, lists the coding agents: seven modules, three installed by default, three optional, and one legacy and off by default. Generated documentation that carries its own provenance comment is a practice worth copying, because it tells a reader whether to trust the text or go and look at the data.

The rest of the repository layout supports the same picture. There is an `acfs/` directory for the installer libraries, `apps/` and `packages/` as Bun workspaces, `scripts/`, `tests/`, `docs/`, a `VERSION` file, a `CHANGELOG.md`, an `AGENTS.md`, a `.shellcheckrc` for the shell sources, a `bun.lock` and a `bunfig.toml`. The build and development scripts are thin wrappers around the web workspace, so the TypeScript in this repository is mostly the wizard site, while the actual provisioning work is Bash and the libraries under `acfs/`.

The per-agent configuration directories at the top level, `.claude/`, `.codex/`, `.cursor/` and `.gemini/`, are the other clue worth noting. A project that ships configuration for four different agent tools is a project that has been used with them, and the manifest's roster of seven suggests the other three are configured from generated metadata rather than a checked-in directory.

The release record tells you where the fragility is

The most informative thing about this project is its own changelog titles, and they are not the titles of a finished system.

Version 0.7.0, published on 2026-06-26, is titled ACFS Update Reliability Release. Version 0.8.0, on 2026-08-25, is titled the installer works again. Version 0.9.0, on 2026-09-04, is titled service repair, per-tool holds with rollback, Gemini 3.8 Antigravity.

A release called the installer works again is a release that says the previous release shipped a broken installer. That is worth more than a polished changelog, because it tells you the failure was in the provisioning path rather than in the environment being provisioned, and it tells you the author is willing to say so. The follow-up release title, per-tool holds with rollback, describes a fix in the same area: a tool that fails can be held and rolled back rather than aborting the run. For a thirty-step installer, that is the single most valuable reliability feature you could add, and it arrived at 0.9.0.

The cadence is fast. Three releases in ten weeks, with a last push on 2026-09-19, and the project is not archived. That is consistent with a solo maintainer iterating on a script whose failures are discovered by running it on new machines.

There is a documentation inconsistency worth flagging, and it is exactly the kind that matters in a project whose main artefact is a command line. The version badge near the top of the README reads 0.7.0, while the newest tag is v0.9.0, the root `package.json` is at version 0.9.0, and the pinning example uses v0.9.0. So the badge is two releases behind, and a reader who trusts it will believe they have installed 0.7.0 when they have installed something else. The `VERSION` file in the repository is the place to check what you actually have, and pinning with `--ref` is what stops the ambiguity from arising at all.

A custom licence with a rider, and the reading you need to do yourself

The licence needs a sentence of its own, because the badge and the classification do not match and the more permissive reading is the wrong one.

GitHub could not classify the licence for this repository and shows it as Other, a custom licence, with the text in the `LICENSE` file. The README badge reads License-MIT+OpenAI/Anthropic Rider. Those two are not in conflict in substance, but the badge is easy to misread as plain MIT, and a custom MIT with an added rider is not MIT: the rider is a condition the original MIT text does not contain, and it was presumably written because this project installs and configures OpenAI and Anthropic tools whose own terms of use are the reason the rider exists.

What that means practically is that the licence file is the only thing to read. MIT alone permits use in commercial settings with attribution and no further obligation. An MIT-plus-rider arrangement can add conditions about which services the installed agents connect to, how accounts are used, or what the configuration is permitted to do, and none of that can be inferred from the badge. This is a description of what the files say rather than legal advice, and the practical step is short: read `LICENSE` before you run the installer on a machine connected to a company account.

The rest of the licensing picture is normal. The project is distributed from source with no compiled artefact of its own; the thing being installed is a collection of third-party tools, each carrying its own licence, which is worth remembering when a compliance review asks what is on the machine after the install runs.

For an evaluator, the summary is this. The engineering in the manifest pipeline, the CDN ordering note, the buffered downloads and the per-tool rollback is above what most bootstrap scripts attempt. The release history says the installer itself has been fragile and is only now being hardened. The defaults are tuned for a disposable VPS and for speed, and the licence is custom. Take it in that order: read the licence, pin the version, then run it on a machine you can throw away.

Editorial conclusion

Run ACFS on a machine you are willing to rebuild, because it enables passwordless sudo, writes shell configuration, and installs thirty-odd tools from a remote script in one pass, and pin the installer to a tagged release with --ref rather than using the unpinned main command in the quick install. Do not run it on a workstation holding anything you have not backed up, and do not treat the checksum ledger as protection against a malicious upstream, since the ledger travels in the same branch as the installer. Verify first by reading LICENSE, which GitHub could not classify, then reading the mode options before you pass --mode vibe, and check the VERSION file against the release you pinned.

Frequently asked questions

Official sources

1. Dicklesworthstone/agentic_coding_flywheel_setup on GitHub
2. Issues
3. Project website
4. README
5. Releases