Daily Edition Sources +7

OpenWork Turns OpenCode Into A Team Workbench

The OpenCode-powered project is building a local-first desktop and server layer so agent work can be run, shared, permissioned, and audited from one product surface.

Diagram Punk poster showing OpenCode as an engine feeding an OpenWork team workbench through evidence cards for README, server APIs, approvals, audit, export safety, UI MCP, and recent hardening commits. — Diagram PunkOpenWork's difference is the workbench around the engine.

repos different-ai/openwork + anomalyco/opencode evidence

7 source signals 2 repos 4 linked commits

Evidence: 4 linked commits / June 17, 2026 / Daily Edition

Open Edition Evidence below

On June 16, different-ai/openwork merged documentation and fixes around hosted topology, database encryption, MCP JWT policy, organization ownership, and admin access, evidence that the OpenCode-based desktop app is becoming a team operations surface.

Facts

The README frames OpenWork as a desktop app for local files, 50-plus LLMs, skills, plugins, MCP servers, and one-link setup sharing.
The server package exposes endpoints for workspaces, events, skills, plugins, MCP, tokens, approvals, audit, import/export, and OpenCode proxying.
The code includes manual approval requests, JSONL audit records, scoped owner/collaborator/viewer tokens, export secret scanning, and a bearer-protected UI MCP bridge.

Evidence

OpenWork differs by productizing the control plane around an existing agent engine. It wraps OpenCode with desktop, server, orchestrator, remote workspace, UI-control MCP, skills, plugins, and share/export mechanics.

Context

The consequence is practical: agent work is moving from one CLI session toward organizational machinery where teams decide who can install a skill, connect a worker, answer a permission prompt, export a setup, or inspect what happened.

Limits

The evidence shows architecture and hardening, not broad adoption. Windows support is framed as paid support, many cloud flows live under enterprise code, and the security commits show an active boundary under construction.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail, limits, and reporting notes on the same page.

Edition

DateJune 17, 2026

LaneDaily Edition

Confidence87%

Sources7

Reposdifferent-ai/openwork, anomalyco/opencode

Primary Evidence

OpenWork repository and README: https://github.com/different-ai/openwork and https://github.com/different-ai/openwork/blob/dev/README.md
- Evidence used: the public framing says OpenWork is a desktop app for doing work with AI agents on local files, powered by OpenCode, with provider keys, skills, plugins, MCP servers, local/remote modes, permission requests, templates, debug exports, and setup sharing.
OpenCode repository: https://github.com/anomalyco/opencode
- Evidence used: the upstream engine context for OpenWork's positioning; OpenWork's own README identifies the app as powered by OpenCode rather than as a replacement engine.
OpenWork AGENTS.md: https://github.com/different-ai/openwork/blob/dev/AGENTS.md
- Evidence used: the project tells contributors it is a practical control surface for local and remote agent workflows, with OpenCode capability reuse, server consumption first, composability, and hosted worker connection.
Server and orchestrator docs: https://github.com/different-ai/openwork/blob/dev/apps/server/README.md and https://github.com/different-ai/openwork/blob/dev/apps/orchestrator/README.md
- Evidence used: OpenWork exposes workspace, event, skill, plugin, MCP, token, approval, audit, import/export, file session, and OpenCode proxy APIs, while the orchestrator runs OpenCode, OpenWork server, and opencode-router together.
Approval, audit, scoped token, and export-safety code: https://github.com/different-ai/openwork/blob/dev/apps/server/src/approvals.ts, https://github.com/different-ai/openwork/blob/dev/apps/server/src/audit.ts, https://github.com/different-ai/openwork/blob/dev/apps/server/src/tokens.ts, and https://github.com/different-ai/openwork/blob/dev/apps/server/src/workspace-export-safety.ts
- Evidence used: the code implements manual approval requests, JSONL audit entries, hashed scoped tokens for owner/collaborator/viewer roles, and secret-signal checks for workspace exports.
UI-control MCP docs and bridge code: https://github.com/different-ai/openwork/blob/dev/docs/mcp-ui-control-profile.md, https://github.com/different-ai/openwork/blob/dev/packages/openwork-ui-mcp/index.mjs, and https://github.com/different-ai/openwork/blob/dev/apps/desktop/electron/ui-control-server.mjs
- Evidence used: OpenWork exposes semantic UI actions through MCP using a localhost HTTP bridge protected by a bearer token and a discovery file.
Recent hardening commits: https://github.com/different-ai/openwork/commit/d4951db, https://github.com/different-ai/openwork/commit/daa9b56, https://github.com/different-ai/openwork/commit/b74b0aa, and https://github.com/different-ai/openwork/commit/53b7434
- Evidence used: the June 15-16 commits harden organization ownership lifecycle, MCP JWT policy, default MCP token scope, and explicit route access policy.

Evidence Limits

The article does not claim broad enterprise adoption or completed security maturity.
The article treats the cloud and enterprise code as project evidence, not as proof that every feature is available to every user.

Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.