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

The problem iPolloWork is aimed at is coordination, not code generation

Most teams that use coding agents end up with the same shape of mess. One person runs Codex, another runs OpenCode, a third has a DeepSeek Harness setup, and each of those has its own plugin directory, its own Skills, its own notion of what a task is. The agents work. The coordination does not. Results live in chat transcripts, extensions get reinstalled per machine, and nobody can say which agent touched which file.

iPolloWork's answer is to make the runtime a detail rather than the organising principle. The README states it plainly: the project "does not split projects or extensions by runtime". Plugins, Skills, agents, commands, services and authorization are installed once and enabled once, with engine-native bindings sitting behind the same lifecycle. A task can be handed to a DeepSeek Harness subagent, and the structured progress comes back into the same project view rather than into a separate conversation.

The intended audience is not an individual developer with one agent. It is a team that already has several, plus non-engineering contributors who need to review, approve and edit what the agents produce. That is a narrower audience than the marketing framing suggests, and it is the audience the design actually fits.

Three runtimes, three integration paths, and they are not equivalent

The compatibility model is the most concrete thing in the README, and it is worth reading carefully because it is where the abstraction leaks.

OpenCode is the default local execution runtime. DeepSeek Harness is described as an optional peer runtime and a subagent delegation target. Codex is, like DeepSeek Harness, an optional peer runtime with native session and tool adapters. Separately, the ipollowork-ui-mcp control surface lets external clients operate the desktop.

So the workbench presents one project view over three runtimes that are attached in different ways. The README acknowledges this directly: these paths "share the workbench while preserving each runtime's capabilities". Each runtime keeps its own agents, Skills, plugins and execution model. If you expect a Codex project and an OpenCode project to behave identically inside iPolloWork, the documentation does not support that expectation.

The delegation model is bounded rather than open-ended. A task can push work to DSH subagents "when useful" and pull structured results back. That is a hub-and-spoke arrangement with iPolloWork as the hub. It is a sensible design for keeping one source of truth, but it means the workbench becomes a dependency for every delegated task.

Getting a first run: two commands and a local port

Official iPolloWork desktop installers are published on GitHub Releases for macOS, Windows and Linux. For DeepSeek Harness users, the README also gives these commands:

npx @deepseek-ai/dsh plugin --profile web add deepseek-idesign deepseek-ippt deepseek-ivideo

followed by:

npx @deepseek-ai/dsh web

That installs iPolloWork's native Design, PPT and Video views into the DSH Web UI. The README says to open http://127.0.0.1:3080, start a conversation, and choose Design, PPT or Video. If dsh is already on the machine, the npx @deepseek-ai/dsh prefix can be replaced with dsh.

The --profile web flag selects the web profile for the plugin install. The README says the product runs locally and supports bringing your own model or provider.

The editable-output claim is the part worth stress-testing

The differentiator iPolloWork leans on hardest is that generated artefacts stay editable. The README's phrasing is that text, images, layouts, timelines and scenes remain editable after generation, and that a deck, web page, visual design or video does not become "a finished file or a chat transcript".

That is a meaningful distinction. Most agent workflows terminate in a rendered artefact: a PDF, a PNG, an MP4. Editing it means starting over or opening a different tool. Keeping timelines and scenes as structured, editable objects implies a project format underneath, and that format is what determines whether the promise holds.

Whether the editable representation is a JSON document, a scene graph, a set of files on disk, or something else, and how conflicts are handled when a human edits a scene that an agent is also modifying, are open questions.

The DeepSeek Harness dependency is a developer preview, and the README says so

The clearest limitation is stated by the project itself. DeepSeek Harness is "currently a developer preview", and plugin compatibility follows its active release line.

Read that as an upgrade contract. If the plugin interface in DSH changes between preview releases, the iPolloWork plugins installed through dsh plugin add are exposed to that change. OpenCode is the default runtime, so a team that wants to avoid the preview dependency can stay on that path.

There is a second constraint hiding in the release cadence. iPolloWork shipped v0.50.31 on 2026-10-29, v0.50.32 on 2026-10-30 and v0.50.33 on 2026-11-02. Patch releases on consecutive days during a preview cycle are normal for active development, but they also mean the surface you integrate against is moving. Anyone pinning iPolloWork in a build pipeline should expect to re-verify the plugin lifecycle after upgrades rather than assume it is stable.

What it is not: a replacement for the agent you already have

The README is unusually direct here. iPolloWork is "not positioned as a replacement for a single coding agent". It is a workspace layer over the ones you already run.

That framing matters for comparison. If your actual need is one coding agent with a predictable extension API, then the direct alternative is the runtime itself: Codex, OpenCode or DeepSeek Harness, used on its own. The difference in approach is not feature parity, it is scope. A single runtime owns its own plugin format, its own task model and its own output, and it does not attempt to reconcile a second runtime's plugin format with a third's. iPolloWork takes on that reconciliation work, and the cost is a layer that must track three upstream projects instead of one.

The other plausible alternative is a general-purpose automation or workflow tool that orchestrates agents as steps. That approach usually treats agent output as an opaque blob passed between stages, which is exactly what iPolloWork is trying to avoid with its editable artefacts. If your outputs are text and code, the simpler orchestration model is probably sufficient. If your outputs are decks, pages, designs and video that people need to keep editing, the opaque-blob model breaks down and the case for a workbench like this gets stronger.

Licence, maintenance and the cost of tracking three upstreams

The repository metadata reports the licence as NOASSERTION. That is a GitHub classification meaning the licence could not be matched to a known SPDX identifier, not a statement that no licence exists. Anyone planning to embed iPolloWork in a commercial product, redistribute it, or ship it inside an enterprise image needs to read the LICENSE file in the repository directly. This is not a legal opinion, and the classification alone tells you nothing about your obligations.

The maintenance picture is mixed. The project is active: last push 2026-11-02 and releases through v0.50.33. There is also an OpenSSF Best Practices badge reference in the README, which points at a self-assessment rather than an audit.

The real cost is not iPolloWork's own release cadence, it is the transitive one. Codex, DeepSeek Harness and OpenCode each ship on their own schedule. iPolloWork's value proposition depends on keeping all three integration paths working, and the README already flags that DSH compatibility follows an active preview line. A team adopting this is signing up to track three upstream projects and validate the workbench after each of their releases. That is the price of the unified workspace, and it is worth stating plainly before anyone plans around it.

Editorial conclusion

Adopt iPolloWork if your team already runs more than one agent runtime and the coordination overhead has become the problem, or if you specifically need generated decks, pages, designs or video to stay editable rather than landing as finished files. Do not adopt it if you need a single coding agent with a stable, well-documented plugin contract, because DeepSeek Harness, one of its runtimes, is still labelled a developer preview. Before committing, verify three things: the actual licence terms behind the NOASSERTION identifier, whether the plugin and Skill lifecycle survives a version bump of your chosen runtime, and whether the editable output formats hold up on the documents and video your team actually produces.

Frequently asked questions

Official sources

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