NextCoWork: a desktop workspace for coding agents with a permission model

The agent is the centre of a workbench, not a chat sidebar

NextCoWork describes itself as a desktop workspace for coding agents, and the one-line summary in the README is a desktop workspace for coding agents.

The longer description spells out what that means: agent-driven development on the desktop, with multiple workspaces side by side, a full workbench of editor, terminal, Git and browser, and an agent kernel with a permission model you can trust, all in one native app for macOS, Windows and Linux.

That framing is the differentiator. The market this sits in is full of chat interfaces bolted onto an editor, where the agent can read and write files and run commands and you are left inferring what it did. NextCoWork puts the workbench and the agent in the same application, so the state the agent is working on and the state you are inspecting are the same state.

The feature list is grouped in a way that tells you what each subsystem is.

Workspaces and sessions means multiple workspaces open in tabs, parallel agent sessions per workspace, and streaming state kept isolated per session. The isolation point matters: two agents working in two workspaces do not share a stream, so you can watch both.

The agent kernel covers streaming replies, tool calls with a per-call approval chain, plan mode, subagents, background tasks, todo reconciliation and scheduled runs.

The workbench gives you a file explorer and editors including plugin-provided custom editors, a real PTY terminal rather than a fake output pane, and background command execution. Git integration covers status, diff, log and branches, with staging, committing, creating and switching branches. There is a built-in browser with per-workspace partitions that share login state with your tabs.

The primary language is TypeScript, the licence is Apache-2.0, and the project is published under the AIDotNet organisation with a site at nextco.work. The last push was on 2026-10-17 and the current release is v2.8.4 from the same day.

Per-call approval is the feature that decides whether you can trust it

The permission model is where the interesting engineering claim sits, and it is stated in two places.

The agent kernel entry lists tool calls with a per-call approval chain. The plugin section says a plugin declares what it contributes and the capabilities it needs, and the host enforces per-call permission gates at runtime. The features list puts it plainly: a manifest-driven plugin system with per-call capability gates.

The distinction between manifest-driven and gate-enforced is the point. A plugin that declares it needs filesystem write access or browser access is announcing it, and the host checks that declaration against each individual call rather than granting a blanket permission for the lifetime of the session. That is a stronger design than the common pattern of a tool that asks once and then acts freely.

The inline visualization feature is the other thing worth understanding, because it is unusual. The agent can render live HTML and SVG widgets, charts, diagrams and interactive UI, directly inside the conversation. The documentation is specific that these are sandboxed in their own iframe and follow the app theme, which is the two properties that make this safe enough to ship: the widget cannot reach the surrounding page, and it does not look foreign in the interface.

Skills and MCP are both supported, with SKILL.md-based skill packages alongside Model Context Protocol support for external tool servers. The repository has a skills/ directory in its examples, and the resources/ directory holds app icons, bundled skills and the plugin runtime.

Together, those features describe a fairly complete model of what an agent can be given and how much of it you have to approve each time. For a tool that can run shell commands on your machine, that is the part to read closely before you trust it with anything.

Installers for three platforms, and a device service for when the laptop is closed

Installation is ordinary for a desktop application. Installers are published for macOS as a .dmg covering both Apple Silicon and Intel, for Windows as an .exe NSIS installer, and for Linux as an .AppImage. The latest stable release is on nextco.work.

The device service is the more interesting piece. The agent does not have to run inside the app. A headless device service, with no Electron and requiring Node.js 24 or newer, can hold the database, the workspaces, Git and the terminals on another machine and keep running while the desktop is closed. The desktop then pairs with it over a certificate-pinned connection.

The commands are published as an npm package.

npm i -g @aidotnet/nextcowork-device-service
ncw-device-service diagnose
ncw-device-service --data-dir ~/ncw-device --host 0.0.0.0 --port 7801 --pairing-port 7800 --advertise nas.lan --invite

The diagnose command is the first thing to run, and the flags show the shape of the thing: a data directory, a host and port for the service itself, a separate pairing port, an advertise address, and an invite flag that produces the pairing string.

Pairing is explicit and the user checks something. You paste the printed ncwpair1.… invitation into Settings, then Devices, then Add device, check the fingerprint, then pair. The certificate pinning is what makes that check meaningful, since the connection refuses a peer whose certificate does not match.

For a home lab, the advertise address of nas.lan in the example is the realistic use case: the agent runs on a machine that stays on, and you connect to it from the desktop on your laptop. The documentation also covers installing the service as a system service, systemd, LaunchDaemon or WinSW, taking over an existing desktop data root, and troubleshooting, in docs/device-service.md.

The Windows service option is WinSW, which is a Java service wrapper, so that path needs a JRE present on the machine.

The build is Electron with a plugin runtime assembled by a script

The project structure section describes an Electron application with a strict separation between processes, and the package manifest shows the scripts that build it.

So the main process owns the agent kernel, the plugin host, IPC, storage and the updater. The renderer is React and holds the chat, workbench, terminal, Git, browser and settings. The preload script is the context bridge, which is where the security boundary sits, and the shared directory holds the types and pure functions both sides use.

The build tooling is electron-vite, with electron.vite.config.ts at the root and a separate tsconfig for the controller client, the node side, the web side and the plugins, so the typecheck script fans out across all four.

npm install        # also runs patch-package and electron-builder install-app-deps
npm run dev        # start the app with hot reload

The dev script is not just electron-vite dev, it first runs build:plugin-runtime, which is a node script that assembles the plugin runtime from scripts/build-plugin-runtime.mjs. There are sibling scripts for the agent and for the relay, and a patches/ directory with patch-package patches, which is how the Electron build is kept working against upstream changes.

The verification commands match what CI runs.

npm run typecheck  # typecheck main + renderer + shared
npm test           # vitest
npm run lint       # eslint

And packaging has two targets, npm run dist for installers for the current platform and npm run dist:dir for an unpacked build for quick checks. There is also a separate npm run e2e that builds and then runs a probe script, and a theme probe for the appearance side.

The engine requirement is Node.js ^20.19.0 or >=22.12.0 with npm, and the app itself is private with main pointing at ./out/main/index.js, and electron-builder.yml handles the installer configuration.

A plugin is a manifest, and the ecosystem ships as separate packages

The plugin system is the piece with its own toolchain, and it is packaged separately from the app.

A plugin is described as a package.json manifest plus optional code. You declare what you contribute, which the README enumerates as commands, menus, keybindings, custom editors, views, web apps, agent tools and bundled skills, and the capabilities you need, and the host enforces per-call permission gates at runtime.

Scaffolding is one command.

npm create nextcowork-plugin@latest

The ecosystem packages are three, and they are under the packages/ directory. The type definitions live in @aidotnet/plugin-api, and the build, package and publish tool is @aidotnet/plugin-cli, whose binary is named nextcowork-plugin. The third is create-nextcowork-plugin, the scaffolder behind the command above.

The examples directory makes the shape concrete. There are samples with acme prefixes, so acme.claude-code, acme.codex, acme.excalidraw, acme.image-studio, acme.markdown-studio, acme.note-editor, acme.think and acme.wechat-exports, plus ncw.bilibili and a skills/ directory. The acme prefix is a convention rather than a company, and the set shows what a plugin can be: a custom editor, a web app, a skills bundle.

There is a top-level plugins/ directory as well as packages/, and the package scripts include typecheck:plugins pointing at plugins/tsconfig.json, so plugin sources are type checked as part of the main typecheck script.

One licensing detail is worth flagging, because it is unusual. The application itself is Apache 2.0, but the plugin ecosystem packages are distributed under the MIT licence, with each package's package.json carrying its own terms. So a plugin you write can be MIT, while the host is Apache, and a company policy that only allows permissive licences in its own tree can still work with this.

Where NextCoWork is the wrong tool

The first wrong-tool case is a team that needs agents running unattended on a server. The desktop app is the primary surface here, and the device service exists to serve a laptop that closes rather than to be the main deployment target. A CI system or a batch pipeline that needs agents to work without a human watching is a different product, and nothing in the visible documentation describes a headless-first workflow with a job queue and no interactive pairing.

The second case is a user who is already invested in an existing editor and agent setup. NextCoWork bundles the editor, the terminal, Git and the browser into one Electron application. If you live in an IDE with its own agent integration, moving to a different workbench means giving up your keybindings, your extensions and your muscle memory, and the permission model does not compensate for that.

The third case is a platform not on the installer list. macOS, Windows and Linux are covered, with the Linux build as an AppImage, which on a distribution with unusual library handling can be awkward, and there is no statement about a portable or tarball Linux build.

There is also a dependency question that comes with any Electron application that is this capable, and the README is reasonably open about it: the app talks to a model provider, it can browse the web, it can run commands, and it can install plugins. The permission model and the pairing fingerprint check are the right answers to that, and the account sign-in flow with a metered wallet balance adds another external dependency. If your organisation requires a model provider you control, the documentation says you can add your own, naming OpenAI, Anthropic and DeepSeek among the options, but the built-in channel is the one that is described in detail.

The release cadence is fast, with v2.8.4, v2.8.3 and v2.8.1 landing within a few days of each other in October 2026, and there is a CHANGELOG.md in the repository root. For an application that can run commands on your machine, that cadence is a consideration rather than a reassurance, and the per-call approval chain is the mitigation.

Editorial conclusion

NextCoWork suits a developer who wants to run coding agents against real workspaces with visible, reviewable tool calls rather than a chat box bolted onto an editor. It does not suit a team that needs its agents to run unattended on a shared server, since the desktop app is the primary surface and the device service is the exception rather than the design, and it does not suit anyone unwilling to deal with an Electron app and a plugin host. Before adopting, read the permission model in the agent kernel section and the plugin capability gates, and try the device service pairing flow early if you need the agent to survive a closed laptop.

Frequently asked questions

Official sources

1. AIDotNet/NextCoWork on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases