Architecture overview
How the Deyin monorepo fits together: branding tokens, host core, agent core, OAuth, and the apps built on them.
Packages
branding — design tokens and logo assets shared everywhere. oauth-provider / oauth-client — the Openference OAuth 2.0 + PKCE implementation. host-core — terminal PTY, filesystem, git, and exec RPC surface exposed to agents and UI. agent-core — session state, permission engine, tool pipeline, and streaming.
Apps
apps/desktop — the Electron-based desktop experience with the workspace panel, embedded browser preview, tray integration, and automations. apps/cli — the deyin TUI/headless binary sharing agent-core sessions with the desktop app. apps/web — the browser client reusing host RPC.
Data flow
Chat streams from the Openference gateway through agent-core, which routes every tool call through the permission engine. Host capabilities (files.tree, files.read, files.write, exec) run in the main process and stream results back as tool-delta events rendered in chat tool cards.
Monorepo layout
The desktop app and CLI are two frontends over one agent package — sessions, skills, and permissions behave identically in both.
packages/
app/ desktop shell (Electron)
cli/ deyin binary + TUI
agent/ agent loop, tools, permissions
gateway/ Openference client + routing
branding/ shared tokens (the site matches it)
mcp/ catalog + transportsData flow
Composer input → agent loop (plans, tool calls) → permission gate → local file and terminal effects. Model traffic exits only through the gateway client; file contents stay on disk except the slices a tool call explicitly reads.
Sessions persist as JSONL under the app data directory, so the CLI can resume a session the desktop app started — and vice versa.