Back to Blog
Voiden 1 to Voiden 2: the changes that matter
D

Davinder singh

07/14/2026

Voiden 1 to Voiden 2: the changes that matter

Voiden 2 shipped across four releases. Here are the changes that actually change how you work: the CLI runner, a protocol-agnostic core, hierarchical inheritance, and preview tabs.

Voiden 2 rolled out across four releases between May and July 2026, from the first 2.0.0 beta to v2.2.1. The changelogs list everything. This post doesn't. It skips the long tail of small fixes and covers the handful of changes that change how you actually work with Voiden, and why we made them.

Your .void files now run without Voiden

The biggest change in Voiden 2 doesn't live in the app at all. @voiden/runner is a standalone CLI that executes .void files anywhere Node.js 18+ is available. No GUI, no desktop app.

voiden-runner run test.void

The request fires, results print to the terminal, and the process exits with a standard exit code your CI system can act on.

Why this matters: your API requests, docs, and tests already live in Git as plain Markdown. Now the same files can gate a pipeline. You design a request in the desktop app, commit it, and a GitHub Actions job runs it on every push. Or a cron job runs it every night. Or a Docker container runs it wherever you need it. The file you authored is the file that runs. There's no export step and no second format to keep in sync.

The details:

  • Output formats: human-readable by default, --json for machines, --csv for reports, --mail to send a formatted HTML report over SMTP.
  • Request chaining: runtime variables persist between requests, same as in the app. A value captured from one response is available in the next via {{process.KEY}}, no extra setup.
  • Same plugins: the five core plugins (scripting, assertions, faker, advanced auth, GraphQL) run identically in the CLI and the desktop app.
  • Protocols: REST, WebSocket, gRPC, and GraphQL are all supported.

Full docs, including CI examples for GitHub Actions and GitLab CI, are at docs.voiden.md.

The core no longer knows what a protocol is

v2.0.0 restructured the request engine to be protocol-agnostic. REST, WebSocket, and gRPC logic moved entirely into their respective plugins. Each core plugin now lives in its own repository, with its own versioning and releases. @voiden/create-plugin scaffolds a plugin workspace in one command, and the SDK grew real capabilities: top bar buttons, declarative settings fields, a project file system API, all gated behind a manifest permission system where a plugin declares exactly what it needs.

We've been on the wrong side of this before. Fusion, the internal project that came before Voiden, had extensibility but not openness, and we became the bottleneck ourselves. If community plugins are the plan, and they are, the architecture has to actually make room for them. Moving protocol logic out of the core is what "making room" looks like in practice: if REST itself is just a plugin, there's nothing a community plugin is second-class to.

Shared config now cascades down folders

v2.2.0 added hierarchical inheritance (#469). A folder-level .voiden-inherited file cascades auth, headers, and other shared config down to every request nested inside it.

Before, composability stopped at the block level: you could reuse an auth block, but you still had to link it into every file. Now it works at the folder level too. Forty requests under one API, one place where the bearer token lives. Change it once, every request under that folder picks it up. The inheritance is visible in a plain file you can read and diff, not applied invisibly at runtime.

Preview tabs, because this is an editor

Single-clicking a file now opens it in a reusable preview tab that gets replaced by the next preview. Editing it, or opening it deliberately, makes it permanent. If you use VS Code, you already know this behavior.

It's a small feature with a real signal behind it. Voiden has always been closer to an API IDE than an API client, and this is the kind of behavior that claim has to cash out in: you can browse a repo with thirty .void files without ending up with thirty open tabs. v2.2.1 tightened it further, fixing a bug where Cmd/Ctrl+Enter from a preview tab would silently promote it to a permanent one.

Reliability fixes that change behavior

We're not going to list every fix. Three are worth knowing because they change what the app does, not just how well it does it:

  • Requests with unresolved variables no longer send. If substitution leaves a literal {{variable}} in the request, Voiden blocks it. A request going over the wire with placeholder text in it was worse than an error message.
  • Large integers survive intact. The response viewer and runtime variables now parse JSON losslessly, so 64-bit IDs stop getting silently rounded by JavaScript's native parser.
  • Quitting with unsaved tabs no longer silently saves everything to disk. You now get a dialog listing the unsaved tabs, with Save All & Quit, Don't Save, or Cancel. Writing to your files without asking is hidden behavior, and hidden behavior is a bug.

Alongside these: description columns in headers and params tables so each row carries its own documentation, plugin update notifications, cURL extenders so plugins can inject their own auth into "Copy as cURL" output, and code ligature support in the editor.

Where this leaves Voiden 2

Voiden 1 was a desktop app that kept your API work in Git. Voiden 2 is the version where those files start working on their own: in your terminal, in your pipeline, in whatever plugin someone builds next.

Download Voiden at voiden.md/download, or dig into the code at github.com/VoidenHQ/voiden.

Related Posts