OpenWork Architecture and Runtime
1. The workspace shape​
The README reveals these core runtime surfaces:
| Area | Why it matters |
|---|---|
| desktop app | local UI shell |
| host mode | local orchestration stack |
| client mode | connect to an existing server |
| OpenCode runtime | powers sessions and tasks |
| skills and plugin management | extend workflows |
| permissions and timeline UI | expose decisions and progress |
This is a richer structure than a simple chat window.
2. The runtime mental model​
At runtime, OpenWork generally does this:
- the user picks a workspace or server,
- the host or client connection is established,
- OpenCode runs the underlying workflow,
- sessions stream updates via SSE,
- todos, permissions, and debug information appear in the UI.
3. Why host mode matters​
Host mode is one of the clearest examples of OpenWork's design goal. The product wants to make local orchestration easy without forcing users to manually manage every CLI piece.
4. Why permissions are a first-class concept​
The README explicitly lists permission requests and choices like allow once, always, or deny. That means OpenWork should be understood as:
an OpenCode workbench plus a human control layer
not just as a prettier frontend.
5. What to read first in code​
Start with:
- the README setup and architecture notes,
apps/app,apps/desktop,- orchestrator-related code,
- plugin and skill management surfaces.