code-server is a production-grade application that runs Visual Studio Code on a remote server, making it accessible via any modern web browser. It is not a research or data pipeline project; it is a full-stack web application with a Node.js/Express backend, WebSocket support, and extensive CLI tooling. The system authenticates users via password (argon2 hashing) or custom auth, manages VS Code server processes as child processes, and provides proxying for local services (path-based and domain-based). It includes a Helm chart for Kubernetes deployment, Docker images for multiple Linux distributions, and an install script for various platforms. The architecture is a monolith with a parent/child process wrapper for graceful restarts and signal handling, and it relies on external dependencies such as VS Code itself (as a submodule with quilt patches), Express, ws, httpolyglot, and argon2. Key entry points include src/node/entry.ts (CLI parsing and server startup), src/node/main.ts (server creation), and src/node/app.ts (Express app and WebSocket router setup). The codebase is heavily patched (27+ .diff files) to adapt VS Code for remote use, adding features like base path support, custom marketplace, telemetry, logout, and iframe integration. While the patching approach is fragile and tightly coupled to VS Code's internal APIs, the core server infrastructure and many utility modules are well-architected and reusable.

Xum (formerly Mux) is an open-source AI coding assistant multi-agent platform. Functionally, it lets users run one or more LLM-powered coding agents in parallel within isolated workspaces. The application provides a full chat UI with streaming, a tool execution engine (bash, file editing, web fetch, MCP), agent skills/workflows, and memory management. It supports multiple AI providers (Anthropic, OpenAI, Google, etc.) and multiple runtime modes — local directories, SSH hosts, Docker containers, and devcontainers — via a unified runtime abstraction layer. Architecture: The system is a hybrid monolith/dual-deployment. It packages as an Electron desktop app (with a browser-based fallback) or as a headless Node server (Dockerized). Typed IPC is handled by in-house oRPC over WebSocket/MessagePort. Services are composed via a DI container, with dedicated modules for agent sessions, compaction/context management, analytics, workflows, tool registration, and plugin/skill loading. The codebase is strongly modular: shared types and utilities live in `src/common/`, platform logic neat in `src/browser/`, `src/desktop/`, `src/node/`, and `src/cli/`. The VS Code extension in `vscode/` uses shared UI primitives. Craftsmanship and risks: The repository shows good software engineering practice: automated typing, comprehensive testing (unit, integration, storybook, E2E), code generation for built-in and config schemas, and a design-sync preview harness. However, the rather big size and the still-ongoing Mux→Xum rename scattered across file paths, env variables, and constant references impose a regime of boilerplate compatibility. Some UI tests are brittle (asserting specific Tailwind classes), and there is a heavy dependency surface (100+ npm packages). Overall the codebase is professional and well-structured.

envbuilder is a CLI tool written in Go that builds and runs Dev Containers (as defined by devcontainer.json) inside Docker containers, using a forked version of Kaniko for image building. In production, it clones a Git repository, locates a devcontainer.json or Dockerfile, compiles a Dockerfile with requested features, builds the image via Kaniko (with layer caching), and then executes lifecycle scripts (onCreate, postCreate, etc.) before running an init command as a specified user. It is designed to integrate with Coder workspaces for log forwarding but can operate standalone. The architecture is a single binary with modular components: options parsing (options/), Git operations (git/), devcontainer spec handling (devcontainer/), Kaniko build orchestration (envbuilder.go), and logging (log/). It relies on system calls for user switching (setuid), execution (exec), and filesystem mounts. External dependencies include Git, Docker daemon, and the Kaniko fork. The tool supports extensive configuration via CLI flags and environment variables, with legacy variable support. Key entry points are cmd/envbuilder/main.go (CLI) and envbuilder.go (Run function). The primary data flow is: input options -> clone repo -> parse devcontainer -> compile Dockerfile -> Kaniko build -> execute lifecycle scripts -> setuid -> exec init. The tool also includes a cache probe mode for checking layer availability without full build.