Wegent: a self-hostable AI workspace that runs coding tasks on your desktop, remote machines or a team server

What Wegent solves, and for whom

A coding agent that only exists on one laptop has a ceiling. The moment a task needs a second machine, a second person, or a run that outlives your terminal session, the conversation and the diff end up in different places. Wegent is built around that gap. The README describes it as "an open-source AI work system spanning your local desktop, cloud agents, and remote machines", and the three named parts map onto that: Wegent Desktop for local projects, files, commands, tests and code changes, Wegent Web for browser-based agents, knowledge, automation and administration, and Wegent Backend as the shared layer for project spaces, models and execution devices.

The intended user is a developer or a small team already comfortable with an agent that edits files and runs tests. The README is explicit that the local experience is Codex-based and that connecting to the backend is optional: if work always stays on one computer, Desktop alone is the product. The team features only start to matter when a task has to run somewhere other than the machine you are sitting at, or when the task board, shared files and execution history need to be visible to more than one person.

The Wework, DSH and Executor layering

The architecture is more layered than the feature list suggests, and the README's own diagram is the clearest statement of it. Wework is the desktop workbench. Electron owns desktop windows, system capabilities and process management. DeepSeek Harness (DSH) is the embedded application and plugin runtime, and the Wework product UI is composed from a set of DSH plugins rather than shipped as one application bundle. Executor manages tasks and sessions, then drives Codex to perform the actual work in local projects.

The plugin split is the part worth understanding before you commit. DSH Core handles plugin discovery, dependency injection and lifecycle. dsh-app-wework is the product shell and UI extension points. dsh-ui-* plugins provide tasks, project spaces, settings, apps and automation. dsh-electron-host bridges Electron capabilities, dsh-executor-runtime adapts task execution and events, and dsh-terminal-runtime provides local interactive terminals. The repository layout backs this up: there are separate top-level directories for wework, wework-mobile, executor, executor_manager, chat_shell, knowledge_engine, knowledge_runtime and knowledge_doc_converter, plus a sdk/ directory and a wegent-cli/ directory.

That is a deliberate trade. A plugin runtime plus a separate executor plus a separate knowledge stack means you can replace a piece without forking the whole product. It also means the surface you have to reason about when something fails is wider than a single process.

Installing Wegent and running a first task

The repository ships an install.sh at the top level and a Docker Compose stack, and the README points at the releases page for the desktop build. The workspace is declared with pnpm and pins the package manager, so a source checkout expects that toolchain rather than npm or yarn.

corepack enable
corepack prepare [email protected] --activate
pnpm install
pnpm build

The root package.json declares "packageManager": "[email protected]" and an engines field of node >= 20, so check the Node version before running install. The build script is pnpm -r --if-present build, which recurses across the workspace and skips packages that define no build step. A prepare:builtin-plugins script exists for syncing built-in plugins, which is the step that populates the DSH plugin set the desktop shell expects.

For the server side, the repository provides a Compose file. Copying the environment template is the documented starting point, and the file itself says so in its header comment.

cp .env.example .env
docker compose up -d

The Compose file defines MySQL 9.4, Redis 7 and an Elasticsearch 8.18.8 service. Elasticsearch is gated behind a profile named rag, so a plain docker compose up does not start it. MySQL defaults to database task_manager with user task_user, and the ports are parameterised through MYSQL_PORT, REDIS_PORT and ES_PORT with defaults of 3306, 6379 and 9200.

The environment template also exposes WEGENT_SOCKET_URL, which the file documents as the address browsers use to reach the backend, not the internal Docker network address. For a remote deployment the comment tells you to use the machine's IP instead of localhost. Two other keys matter if you plan to use attachments or cross-device transcripts: ATTACHMENT_PUBLIC_BASE_URL is described as required when image or video generation uses locally uploaded references, and WEWORK_TRANSCRIPT_ENCRYPTION_SECRET is described as something to keep stable while encrypted transcript objects are retained. Changing that secret after transcripts exist is the kind of mistake the comment is warning about.

Once the desktop build is running, the README's description of the task view is the thing to check first: conversation, tool activity, tests, changed files and diffs in one place. If your first task does not surface a diff and a test result side by side, the executor is not wired up the way the README describes.

Where Wegent is the wrong tool

The honest limitation is operational weight. A pnpm monorepo with a TypeScript workspace, a Python backend with its own formatter and import-sorting configuration, a Rust backend directory, a chat shell, a knowledge engine and a knowledge runtime is not a single binary you drop on a server. The Compose file alone brings up MySQL and Redis before you have run a single task, and Elasticsearch joins them if you enable the rag profile. If your requirement is a local agent on one laptop, most of that stack is dead weight, and the README admits as much by framing the backend connection as the point at which work moves beyond one computer or one person.

The second limitation is version churn. The recent releases include wework-v0.4.4-beta.5 and wework-v0.4.4-beta.4, both published on 2026-09-10, alongside v2.0.18 published on 2026-09-09. Two beta builds of the desktop workbench in the same day, with the main product line on a different version number, means the desktop and the platform are versioned separately. If you deploy the backend and hand out desktop builds, you own that compatibility matrix. The README does not document a rollback procedure for a desktop build that turns out to be incompatible with your backend.

A third boundary: the plugin runtime is the extension mechanism, and the README names the DSH plugins but does not describe what happens when a third-party plugin fails to load or how to disable one. Treat the plugin set as part of the product until you have read the plugin documentation.

How Wegent differs from running Codex on its own

The obvious alternative is running Codex by itself on your own machine. The difference is not the coding quality, since Wegent drives Codex for the actual work. The difference is everything around the session. Codex on a laptop gives you a conversation and a set of file edits. Wegent Desktop wraps that in a project and task structure, keeps tool activity, tests and diffs in the same view, and adds a project-space view with a board, shared files, automation and execution status.

The second alternative is a browser-based agent platform with no local desktop component. Wegent's answer to that is the opposite direction: the local environment is the default execution target, and remote work machines or server-managed executors are additional targets rather than the only option. The README states that once Desktop is connected to the backend, the desktop workbench and Web use the same projects, tasks and execution devices. That shared identity is the specific thing a pure web agent cannot offer, because it has no local project to fall back on.

Wegent also ships its own CLI and SDK directories, which suggests the intended integration path for teams that want to script against the platform rather than click through the UI. The README does not document those surfaces, so treat them as repository evidence rather than a supported contract.

Maintenance, licensing and what upgrades cost

The repository is not archived, and the last push was on 2026-09-10. The release cadence is rapid: v2.0.18 on 2026-09-09, then two desktop betas the following day. The desktop line is explicitly labelled beta in the release names, so pinning a specific wework build is more realistic than tracking latest.

Licensing is Apache-2.0 at the repository root, and the source files carry SPDX headers naming Weibo, Inc. as the copyright holder, for example SPDX-License-Identifier: Apache-2.0 in docker-compose.yml and pyproject.toml. There is a LICENSES/ directory alongside the LICENSE file, which usually indicates bundled third-party components with their own terms. Check that directory before redistributing a build, particularly around the desktop Electron bundle and the embedded runtime.

Upgrade cost is dominated by two things. The first is the database: MySQL is a stateful Compose service with a named volume, so schema changes between backend versions are your migration problem. The second is the transcript encryption secret, which the environment template says to keep stable while encrypted objects are retained. Rotating it is not a routine operation.

Editorial conclusion

Adopt Wegent if you already work in Codex-style local coding sessions and need those sessions to reach a second machine or a teammate without moving the code. Do not adopt it if you want a single binary or a managed service: this is a pnpm monorepo plus a Python and Rust backend plus MySQL, Redis and an optional Elasticsearch profile. Verify first that your Node version is 20 or newer, that pnpm resolves to the 11.7.0 the workspace pins, and that you can reach an S3 or MinIO endpoint if you intend to use cross-device Wework transcripts.

Frequently asked questions

Official sources

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