Developer guide

📄️ Wework Chat State Sources

This document records the state sources for the Wework chat path. The goal is to make UI code read one explicit derived status instead of letting the send button, message stream, queue, and runtime task list override each other.

📄️ Wework Plugin Marketplace V2

For plugin development, open-source migration, and local integration, start with the Plugin Marketplace Developer Guide. This document focuses on the control-plane architecture, data model, and operational constraints.

📄️ Wework Plugin Marketplace Developer Guide

For developers who need to build, migrate, or publish Wework plugins. See Plugin Marketplace V2 for architecture and operations, and Codex Plugin Runtime for local runtime details.

📄️ Local Data Directory

Wework stores its local runtime data under ~/.wework in the user's home

📄️ Codex sidebar state parity

The Wework desktop app follows the Codex App sidebar state model. Project and live task content comes from the Codex app-server, while sidebar metadata comes from .codex-global-state.json in the target device's CODEX_HOME. While a remote device is online, Wework also stores a local task-list summary for startup recovery after that device goes offline.

📄️ Wework macOS Release

English | 简体中文

📄️ Local-First Cloud Connection

Wework remains a complete local app by default. Local Codex, local model configs, the local executor, local workspaces, and local conversations do not require Backend login or cloud devices. Cloud connection is an optional capability layer: after the user enters a Backend URL from the sidebar and signs in with the WeWork login flow, server models, cloud devices, and cloud Codex auth sync join the same workbench.

📄️ Codex Plugin Runtime

Wework's plugin feature is compatible with Codex plugins, skills, and apps. The plugin pages handle discovery, installation, creation, and management; the chat runtime passes user-selected skills and apps to the Codex app-server as structured mentions instead of treating display text as plain prompt content.

📄️ Performance Diagnostics

Wework includes an opt-in frontend performance diagnostics switch for investigating release builds that become slow after running for a while. The diagnostics code only runs after it is explicitly enabled; when disabled, the app does not install React Profiler and does not collect interval samples.

📄️ E2E Automation

Wework provides a dedicated Playwright E2E entrypoint and a test-only frontend automation bridge for operating the Wework Vite/React frontend in CI. The default entrypoint runs in browser mode, which covers most frontend interactions; the desktop task-flow E2E below covers native-window and task-execution behavior.

📄️ Workspace File Preview

The Wework file panel renders Markdown documents as formatted content, sends other code and text files to Pierre CodeView, and sends binary files to Flyfish Viewer browser-side renderers. Preview data is read only from authorized local workspaces and is never uploaded to third-party services.

📄️ Debug Instance Labels

Wework can launch a debug Wework instance from the built-in Terminal of another running Wework window. To keep multiple worktrees and dev apps distinguishable, Wework passes the parent window context into the Terminal, and wework/scripts/dev-mac-app.sh forwards it to the debug instance.

📄️ Plugin Interactive Forms

Wework supports interactive forms from plugins during a running conversation. The user sees a form card in chat, selects or enters answers, and submits the response back to the running plugin. Plugin authors should trigger this through MCP elicitation. requestuserinput is an internal render protocol between executor and Wework and should not be emitted directly by plugins.

📄️ Embedded Browser

Wework's embedded browser displays an interactive web page inside the desktop workbench right panel and lets the local runtime control the same page through the WKWebView bridge. It is not a screenshot preview, and it should not open a separate external Chrome window.

📄️ AI Verification Sessions

Wework can start an isolated development verification session so an AI can operate and assert against the real Tauri application. It reuses the desktop E2E WebView control channel, never drives an external Chrome window, and does not attach to a developer's everyday Wework window.