Skip to main content

​
Runtime topology

TurenOS Desktop runs three principal layers:
  1. The Electron main process owns windows, OS integration, Safe Storage, updates, and sidecar supervision.
  2. The renderer provides projects, sessions, tools, Extensions, review, and settings UI.
  3. The bundled forge sidecar owns the local HTTP API, durable storage, providers, tools, permissions, and execution.
Additional TurenOS servers and WSL environments are separate locations with their own services and state.

​
Trust boundaries

  • Model providers receive selected prompt and context data.
  • MCP servers expose external tools and data under reviewed manifests and allowlists.
  • Filesystem and shell tools act with the local user’s privileges after permission evaluation.
  • Static analyzers inspect selected bytes without executing targets.
  • Desktop IPC exposes an allowlisted preload API rather than direct Node access to the renderer.

​
Local-first does not mean isolated

Sessions and configuration are local by default, but a connected provider, MCP server, fetched URL, remote TurenOS server, or approved command can cross the machine boundary. TurenOS is not a sandbox. Use operating-system isolation, containers, or virtual machines for hostile code and untrusted execution.

​
Durable state

SQLite-backed services store sessions, prompts, tool results, project state, Extensions, automations, goals, memory, and Desktop product settings. Credentials are encrypted separately through the Secret Vault.

​
Reporting security issues

Use the private GitHub Security Advisory form for turenlabs/turenos. Do not open a public issue containing an unpatched vulnerability or credential.