CodePapr is not a monolith — it is a host daemon plus several thin clients

Process topology

Four kinds of executables: clients (codepapr / codepapr-cli), the host (codepapr-server), the Node agent sidecar (agent-runtime.mjs, launched by the host), and the child processes the host manages (LSP servers, shells, MCP stdio servers).

Desktop client codepapr             CLI codepapr-cli
React+Monaco · @codepapr/core       ping/doctor/status/git/fs/
src-tauri/src/host.rs (RPC client)  shell/lsp/server/chat
        │   JSON-RPC 2.0, line-delimited        │
        │   TCP 127.0.0.1 (or stdio)            │
        └────────────────┬─────────────────────────┘
                          ▼
           codepapr-server (host)
           handler.rs → initialize / ping + 159 namespaced methods
           tasks.rs  → serial task queue
                          ▼
           codepapr-core (domain library, no Tauri dependency)
           workspace_fs · git_operations · shell · lsp
           symbols · db(SQLite) · snapshot · mcp_host · web
           agent_runtime → Node agent-runtime.mjs sidecar

Two deliberate exceptions where the desktop crate bypasses RPC via a direct path dependency on codepapr-core: Papr App storage (papr_runtime/app_storage.rs calls db::papr_storage_* directly) and secrets (plaintext lives only in the client Stronghold vault, pushed one-way to the host's in-memory store via secrets/import; the host never persists secrets).

JSON-RPC surface

Line-delimited JSON-RPC 2.0, one object per line. --port <N> → TCP (--port 0 lets the kernel pick, --port-file writes the bound port); no --port → stdio. Requests with an id get a response; without one they are notifications. On disconnect, every pending request fails with codepapr-server closed the connection — there is no automatic reconnect.

159 namespaced methods total plus initialize / ping; anything unrecognized returns Unknown JSON-RPC method. Events ride {"method":"event","params":{"event","payload"}} notifications and are re-emitted verbatim on the Tauri event bus, names unchanged: workspace-files-changed, project-stats-progress, codepapr://lsp-managed-status, agent-runtime://frame/exit/permission-request/permission-cancel/workspace-mutated, mcp-confirm-request.

Data flow and persistence

React → invoke() → commands.rs
  → host::call("fs/readTextFile")
  → TCP → handler.rs → validate
  → codepapr_core::workspace_fs
  → result returns to UI

watcher.emit("workspace-files-changed")
  → server wraps as event notification
  → host.rs dispatch_incoming_line
  → app.emit(event, payload)
  → React listen(event, ...)

All three are opened by codepapr-core::db, i.e. the host process writes them (app storage is the one in-process exception). Legacy state.json/project.json import into SQLite on first open or save.

App / plugin marketplace and scope

.papr apps install from the official registry mmrqwe/codepapr-apps → registry.json into a global or workspace scope.

Each app gets one origin codepapr-app://<appId>/; CSP is derived from two permission axes (local access × network) — with network off, script-src disallows https:. db.sqlite (and wal/shm) is never served over the protocol. A directory counts as an app only when its name is valid, manifest.json parses, and the entry file exists.

Context layering (TypeScript side)

Side effects are delegated to the host; prompt assembly and cache partitioning stay in @codepapr/core (TS side). Full detail: docs/adr/ADR-001…016.

Project memory is authoritative in the workspace file .CodePapr/MEMORY.md: the built-in memory curator maintains it at the delivery / pre-compaction checkpoints, and it is injected into 02 in full every turn (effective the next turn after saving); the Agent has no memory tools and direct writes are rejected. The panel is that file's editor.