iPolloWork: a local-first workbench that puts Codex, DeepSeek Harness and OpenCode behind one project view

The problem iPolloWork is aimed at, and the team it assumes you have

Most agent tooling assumes one runtime. You pick Codex, or you pick OpenCode, and your project structure, your plugin set and your task history are shaped around that choice. Switch engines and you rebuild the scaffolding. iPolloWork's stated position is that it is not a replacement for a single coding agent; the README says it connects Codex, DeepSeek Harness and OpenCode through explicit compatibility boundaries while preserving each ecosystem's native strengths. The unit of organisation is the project, not the chat. People and agents share one view of responsibilities, tasks, schedules, execution health and results. That framing tells you who this is for: teams running more than one engine, or teams whose output is not only code. The README is direct that coding is the starting point and that decks, web pages, designs and video should stay editable after generation rather than becoming a finished file or a chat transcript. If your work is a single repository and a single model, the workbench layer is cost without benefit.

How the multi-engine layer actually fits together

The architecture is a workspace that owns projects and delegates execution. OpenCode is described as the default local execution runtime today. DeepSeek Harness is integrated as an optional peer runtime and as a subagent delegation target. Codex connects through the ipollowork-ui-mcp control surface on npm, and the README is careful to say MCP is the integration protocol for that path, not a fourth agent engine sitting alongside the other three. That distinction matters because it sets expectations: the three runtimes do not expose identical capabilities, and the README says the paths share the workbench without pretending otherwise. The delegation model is bounded. A task can hand a scoped piece of work to DSH subagents, then bring structured progress and results back into the same project. Each runtime keeps its own agents, Skills, plugins and execution model. Extension management is centralised instead: plugins, Skills, agents, commands, services and authorisation are installed, enabled, updated and uninstalled once, with engine-native bindings kept behind the same lifecycle. The repository layout reflects this, with separate .codex/, .opencode/ and .agents/ directories at the top level and a pnpm workspace underneath.

Installing iPolloWork and running your first delegated task

The repository is a pnpm workspace with a setup script, and the root package.json is private and named @ipollo/ipollowork-workspace. The README section on installing iPolloWork is truncated in what is available, so the commands below come from the package.json scripts rather than from a documented quickstart. Run setup first; it is the entry point the repository defines for preparing the workspace.

pnpm setup

After setup completes, the root package.json defines a combined check script that runs the workspace's own verification. Use it before starting any dev server, because it is the only pre-flight the repository declares.

pnpm check

To start the desktop application in development mode, the repository defines a dev script that sets IPOLLOWORK_DEV_MODE and a remote debug port before filtering to the @ipollowork/desktop package.

export IPOLLOWORK_DEV_MODE=1
export IPOLLOWORK_ELECTRON_REMOTE_DEBUG_PORT=9823
pnpm --filter @ipollowork/desktop dev

If you only want the UI layer rather than the full desktop shell, the repository separates it: the dev:ui script filters to @ipollowork/app instead. That is the lighter path when you are evaluating the workbench before committing a team to it.

pnpm --filter @ipollowork/app dev

The README does not state which ports these dev scripts listen on, so treat the terminal output as the source of truth for the URL rather than assuming one.

Where iPolloWork is the wrong tool

The README does not document rollback, and that is a real gap rather than a documentation nit. If you enable a plugin or a Skill across a project and it misbehaves, the README describes install, enable, update and uninstall but not how to revert a project to a prior working state. Treat that as something to establish yourself before you put a team on it. The second limitation is stated by the project: DeepSeek Harness is a developer preview, and plugin compatibility follows its active release line. If your workflow depends on DSH subagents, you are tracking a moving target. Third, the compatibility boundaries are deliberate, which means a capability that exists natively in one runtime may not surface identically through the workbench. A team that picks iPolloWork specifically to get Codex behaviour will find that path goes through MCP, not through a native Codex integration. Finally, if you need a single coding agent in a terminal, none of this applies to you. The overhead of a project view, a plugin lifecycle and a multi-runtime abstraction is only worth paying when you actually have multiple runtimes or non-code deliverables.

How this differs from picking one agent runtime and staying there

The obvious alternative is to adopt OpenCode alone and skip the workbench. OpenCode is already the default local execution runtime inside iPolloWork, so choosing it directly gives you the same execution engine without the project layer, the unified plugin lifecycle or the cross-runtime task view. The difference is in what you give up: with OpenCode alone, plugin and Skill management stays inside that ecosystem, and there is no shared project surface where a human reviews agent progress and approves actions. A second alternative is to run Codex directly and let it own the workflow. That path is narrower in a specific way. iPolloWork reaches Codex through ipollowork-ui-mcp, so standing up Codex on its own removes an MCP hop and the compatibility boundary that comes with it, at the cost of the multi-engine coordination the workbench exists to provide. Neither alternative is worse in the abstract. They are worse if your actual problem is coordinating several engines and several output types under one review process.

Maintenance rhythm, licence and the cost of upgrading

The last push to the default branch was on 2026-09-10, and the repository is not archived. Recent releases are close together: v0.50.12 and ipollowork-orchestrator v0.50.12 both landed on 2026-08-31, with v0.50.8 two days earlier on 2026-08-30. That cadence is worth noting for upgrade planning, because a unified extension system means a plugin, Skill or engine-native binding can break on a version bump that looks minor. Note also that the root package.json declares version 0.18.0 while the releases are tagged v0.50.x, so the workspace version and the release tag do not move together. On licensing, the repository reports NOASSERTION, which means the licence could not be classified automatically. A LICENSE file and a LICENSES/ directory exist at the top level alongside REUSE.toml, so the terms are present in the repository, but the README does not state which licence applies to which part. If your organisation requires a known licence before adoption, read those files rather than the metadata field.

Editorial conclusion

Adopt iPolloWork if your team already juggles more than one agent runtime and wants one project view for tasks, plugins and editable outputs, and if you are comfortable that the licence file is not machine-classified and the README does not document rollback. Skip it if you only need a single coding agent, since the workbench layer is overhead you will pay for and never use. Verify first that pnpm setup completes on your platform, that the DSH plugin path works against the current developer preview release line, and that the LICENSES/ directory covers the terms your organisation requires.

Frequently asked questions

Official sources

1. Devin-AXIS/iPolloWork on GitHub
2. Issues
3. Project website
4. README
5. Releases