iPolloWork: a local-first workbench that puts Codex, DeepSeek Harness and OpenCode behind one project view
Enterprise-grade, local-first Agent Workbench for people and agent teams. A unified multi-engine workspace for Codex Harness, DeepSeek Harness, and OpenCode, with unified plugins and Skills, multi-agent projects and tasks, and editable code, documents, presentations, design, and video.
At a glance
- What is it?
- iPolloWork is a TypeScript workspace that treats agent runtimes as interchangeable execution back ends while keeping plugins, Skills, tasks and editable outputs in one place. The idea is sound; the maturity of the pieces you would actually depend on is the open question.
- Who is it for?
- 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 the runtime iPolloWork leans on most is still labelled a developer preview.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
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 connects through ipollowork-ui-mcp, an npm package that acts as a control surface. The README is explicit that MCP is the integration protocol for that path and not a fourth agent engine sitting alongside the other three.
So the workbench presents one project view over three runtimes that are attached in three different ways, at three different depths. The README acknowledges this directly: these paths "share the workbench without pretending that every runtime has the same native 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
The README gives one complete, copyable install path, and it is for the DeepSeek Harness side rather than for iPolloWork itself. The stated commands are:
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 is the only configuration key visible in the supplied material, and it selects the web profile for the plugin install. The README does not document a configuration file, environment variables, a provider or model selection mechanism, or a project initialisation command for the workbench itself. It says the product runs locally and supports bringing your own model or provider, but the supplied text stops before showing how that is configured. Treat that as an unknown to resolve from the repository rather than something to assume.
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.
The supplied material does not describe that format. It does not say whether the editable representation is a JSON document, a scene graph, a set of files on disk, or something else, and it does not describe how conflicts are handled when a human edits a scene that an agent is also modifying. The topics list includes visual-editor, which suggests a UI layer exists, but the README does not document its behaviour. This is the single largest gap between what the project claims and what the material supports, and it is the first thing to check in the repository.
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. The README does not describe a compatibility matrix, a pinned version range, or a fallback for when a plugin stops loading. OpenCode is the default runtime, so a team that wants to avoid the preview dependency can stay on that path, but then it loses the Design, PPT and Video views, which are documented only for the DSH route.
There is a second constraint hiding in the release cadence. iPolloWork shipped v0.50.8 on 2026-08-30 and v0.50.12 on 2026-08-31, with a separate ipollowork-orchestrator package versioned in lockstep. 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. The supplied material does not include the licence text. 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-09-10, releases through v0.50.12, and a separate orchestrator package released under its own version tag. 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 the runtime iPolloWork leans on most 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.
Community notes