OpenWork

OpenWork Diagnostics is a Vercel-native MCP (Model Context Protocol) compatibility endpoint designed for enterprise troubleshooting. It allows an organization to allowlist a stable host, point an MCP client to the /mcp endpoint, and use an authenticated dashboard to inspect redacted request/response sequences.

Key features include:

• Connections Dashboard: Maintains a seven-day rolling record of metadata-only OpenWork Connect incidents, correlating desktop maintenance probes with Den lifecycle requests (initialize, initialized, tools/list).
• Controlled Den Egress: Supports diagnostic runs for private-cloud and Kubernetes deployments where requests originate within the Den process to exercise real network paths (DNS, proxy, TLS, firewall, etc.).
• Synthetic Profiles: Supports one active profile at a time: generic, microsoft, or servicenow.

The Worker Routes in the Den API manage the complete lifecycle of workers, including runtime management, billing, and heartbeat monitoring. The routes are organized into several functional modules:

• Core Worker Management: Handled by core.ts, providing endpoints to list, create, get, update, and delete workers, as well as token lookup.
• Worker Heartbeat: Handled by activity.ts, providing an unauthenticated heartbeat endpoint that uses a worker activity token.
• Billing: Handled by billing.ts, providing user-facing cloud worker billing endpoints.
• Runtime Inspection: Handled by runtime.ts, providing endpoints for inspecting worker runtimes and passing through upgrade requests.
• Lifecycle & Infrastructure: Provisioning logic is decoupled from the routes and resides in src/workers/.

OpenWork provides a local-first workspace for agentic work via a desktop app, which can then be extended to other AI agents using OpenWork Connect.

Core Capabilities

• Desktop App: The primary interface for managing files, running agents, creating skills, and connecting services. It supports macOS, Windows, and Linux.
• OpenWork Connect: An MCP-based mechanism that allows your desktop configurations (skills, plugins, MCPs, and connections) to be used within other agents like Codex, Claude Code, Cursor, and OpenCode.
• OpenWork Cloud: The central control plane for managing organization-wide policies, identity (SAML SSO), team roles, and skill marketplaces.
• Hosted Workspaces: Provides persistent cloud-based filesystems and environments so work can continue across different surfaces (Desktop, Slack, Mobile).

den-admin-mcp is a read-only admin analytics MCP (Model Context Protocol) server designed for the OpenWork Den database. It allows AI agents to answer business intelligence questions such as weekly growth rates, retention matrices, and user activity status using real data.

Note on usage: While this package provides a stdio implementation for local development or 'break-glass' scenarios, it is generally preferred to use the hosted endpoint via den-api. The hosted endpoint serves the same toolset over HTTP at /mcp/admin and is authenticated via the desktop's first-party MCP token, removing the need for a DATABASE_URL on client machines.

OpenWork offers three tiers of service. The Enterprise tier includes all features from the Team Starter tier, plus advanced management and compliance tools.

Enterprise Services:

• Managed deployment: Setup of Den (self-hosted or hosted), gateway/LiteLLM, IdP, and version pinning.
• Skill development: Custom skill plugins and marketplace packs.
• MCP consulting: Connecting internal data sources/tools as MCP servers with policy guardrails.

The OpenWork Connect installer provides remote MCP configurations for a variety of AI agents and development environments. You can use the same installer to configure:

• AI Agents/Clients: Codex, ChatGPT Desktop, Claude Code, OpenCode, and any standard MCP client.
• IDE/Editors: Cursor and VS Code.

OpenWork Den is the organization-level control plane for managing OpenWork at scale. It provides the following capabilities:

• Inference Management: Provision inference and control access to model providers for specific members or teams.
• Access Control: Invite teammates, create teams, and manage permissions.
• Policy Enforcement: Set desktop policies, restrict local model access, and control approved app versions.
• Skill Distribution: Publish skills and plugins via marketplaces and assign them to organizations, teams, or individuals.
• Plugin Integration: Import Anthropic-compatible plugins and expose their skills and remote MCPs through the OpenWork MCP.

The @openwork/headless-threads package is a client used to drive native OpenWork threads (sessions) from code without a UI. It is not a runtime; it does not add a chat engine, session store, or model gateway. Instead, it provides a typed interface over the existing OpenWork server surfaces.

Key characteristics:

• Native Integration: Threads created via this client are standard OpenWork sessions. You can open the same conversation in the OpenWork desktop/web UI using the same workspaceId.
• Automated Sequencing: It handles the complex polling logic required to determine when a thread has actually "settled" (i.e., when the assistant has finished working and a new message has appeared), preventing the common mistake of assuming a turn is finished just because the server is no longer "busy."

Saved environment variables do not take effect immediately. They enter a 'pending' state and must be explicitly applied to the runtime environment.

Workflow

1. Save Changes: Add or edit a variable. A pending-changes banner will appear.
2. Apply Changes: Click the Apply changes button. This triggers a warning modal that requires explicit user confirmation.
3. Verification: Once applied, the pending state is cleared. Any new task created in the workspace after applying changes will have access to the updated environment variables (e.g., via process.env in a Node command).