Wegent: a self-hostable workbench that splits coding between a Codex-backed desktop app and a browser agent layer

The gap Wegent targets: coding agents that cannot leave one laptop

Most coding agents are single-player. The conversation, the diff and the test output live in one terminal on one machine, and the moment a second person or a second computer enters the picture you are back to copy-pasting context. Wegent's answer is to treat the local coding session as one execution target among several. The README frames the product as an open-source AI work system spanning local desktop, cloud agents and remote machines, and splits the surface into three pieces: Wegent Desktop for local projects, files, commands, tests and code changes; Wegent Web for browser-based agents, knowledge, automation and administration; and Wegent Backend, which connects the two to shared project spaces, models and execution devices. The intended audience is a team that already likes the Codex style of working and wants the same project to be reachable from a colleague's browser or from a remote work machine without moving the repository. The README is explicit that this is optional: if work always stays on one computer, Wegent Desktop alone gives you a familiar Codex coding experience.

Electron, DSH plugins, Executor, Codex: the actual layering

The architecture diagram in the README is the most informative part of the repository. Wework is the desktop workbench, and Electron owns desktop windows, system capabilities and process management. Inside that host sits DeepSeek Harness, abbreviated DSH, described as the embedded application and plugin runtime. The Wework product UI is not a monolith: it is composed from DSH plugins. DSH Core handles plugin discovery, dependency injection and lifecycle. On top of it sit dsh-app-wework for the product shell and UI extension points, a set of dsh-ui-* plugins for tasks, project spaces, settings, apps and automation, plus dsh-electron-host as the Electron capability bridge, dsh-executor-runtime as the task execution and event adapter, and dsh-terminal-runtime for local interactive terminals. Below the runtime, Executor manages tasks and sessions and drives Codex to do the work in local projects. So the data flow is: a task is created in the UI, routed through the executor runtime plugin, handed to Executor, executed by Codex against files in the local project, and the resulting events flow back up the same path to populate the task view. That is a real separation of concerns rather than a thin wrapper, and it is the reason the same project can be pointed at a local machine or a server-managed executor.

What the README does not tell you about running the server

This is where the material runs out. The README gives no install command, no Docker invocation, no environment variable, no config key and no compose file. It links to a documentation site at wecode-ai.github.io/wegent-docs and to the releases page for the desktop download, and that is the extent of the operational guidance. The features list names what self-hosting is supposed to provide (team access, APIs, permissions, scheduling, knowledge services, remote-device management) without naming a single endpoint, port or manifest. Anyone evaluating Wegent for a team deployment therefore has to treat the docs site as the real source of truth and the README as an orientation document. That is a defensible choice for a project moving this fast, but it means the repository alone cannot answer the first question an operator asks, which is what actually runs where. Treat the absence of a quickstart as a signal to read the docs before promising anyone a rollout date.

Execution targets are the interesting design decision, and the risky one

The claim that carries the most weight is multiple execution targets: run tasks locally, on remote work machines, or with server-managed executors. The README describes the mechanism only at the level of the executor runtime plugin and the Executor component, and it states that once the desktop is connected to the backend, the desktop workbench and Web use the same projects, tasks and execution devices. What it does not describe is how a remote work machine is registered, how credentials for that machine are stored, what happens to a running task when the machine drops offline, or how the executor decides which device is eligible for a given task. Those are exactly the questions that decide whether a self-hosted setup survives contact with a real team. The local-only mode is the low-risk path: it uses the code, files, commands and development environment already on your machine, with no backend in the loop. The moment you connect the backend, you have taken on a distributed system whose failure modes are not enumerated in the README.

Release cadence and what it implies for upgrade cost

The release list shows two parallel lines moving at different speeds. Wework, the desktop product, is on 0.4.4 beta releases, with beta.4 and beta.5 published on the same day. The other line is at v2.0.18, one day earlier. Two version numbers that far apart under one repository mean the desktop shell and the platform are versioned independently, so an upgrade decision is really two decisions. The README does not state a compatibility policy between a given Wework build and a given backend version, and it does not say whether the desktop auto-updates or whether the backend enforces a minimum client version. For a self-hosted deployment that is the practical cost driver: if you pin the backend and let desktop users upgrade freely, you are relying on a compatibility guarantee that is not written down anywhere in the supplied material. If you are evaluating this for a team, ask the maintainers directly which Wework builds are supported against which backend releases before you standardise on a version.

Licence, attribution and the plugin boundary

Wegent is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes. That is a permissive baseline and it is the main reason a team can consider self-hosting this without a legal review cycle. Two caveats follow from the material rather than from legal advice. First, Apache-2.0 covers the repository, but the desktop application embeds Codex and the README names DeepSeek Harness as the plugin runtime, so the terms attached to those components are a separate question the repository does not answer. Second, the plugin architecture invites extension: dsh-app-wework exposes UI extension points and DSH Core performs plugin discovery and dependency injection. Yet the README names no plugin manifest format, no registration API and no versioning contract for third-party plugins. If you plan to build on the extension points rather than just use the product, that missing contract is the thing to resolve first, because plugin interfaces in a pre-1.0 desktop line tend to move.

How Wegent differs from running a plain agent CLI in a shared repo

The obvious alternative is a terminal coding agent plus a shared git remote and a chat channel. That combination is cheaper to operate and has no server to run, and for a two-person team it is probably enough. The difference in approach is that the CLI has no concept of a task as a first-class object. Wegent's task view bundles the conversation, tool activity, tests, changed files and diffs into one record, and the project space layers a board, shared files, discussions, automation, execution history and deliveries on top of it. That is a different bet: it assumes the coordination cost of a team outweighs the cost of running and maintaining a backend. It also assumes you want execution history and automation queues as part of the project rather than as something you assemble from CI logs and chat scrollback. If your work is genuinely single-machine and single-person, the CLI wins on every axis that matters: fewer moving parts, no version skew between desktop and server, no execution-device model to reason about.

Editorial conclusion

Adopt Wegent Desktop if your coding work is Codex-shaped and you want task boards, diffs and execution history in one window without standing up a server. Do not adopt it if you need documented deployment steps, stable interfaces or a plugin API you can build against today: the README describes the DSH runtime but names no plugin entry point, and the Wework desktop line is still on 0.4.4 beta releases. Before committing, verify the self-hosting instructions in the wegent-docs site, confirm which release line the desktop download maps to, and check whether the Apache-2.0 LICENSE file carries any additional notices.

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. wecode-ai/Wegent on GitHub