GenerateSaaSAI agents
The desktop app turns the user's own coding CLIs into a workspace agent, driven by a local companion daemon on their machine - running locally by default, with an optional backend connection.
The desktop app turns the user's own AI into a capable agent for your product, running on their machine. Their own installed coding CLIs (Claude Code, Codex, OpenCode) do the work under their own logins; the app spawns and supervises a local companion daemon that drives them over loopback. By default the AI loop stays entirely on-device, and the user's own subscription or key pays the provider directly - never your API budget. Connecting the app to your backend is an optional, explicit choice (and a buyer can forbid it with config.desktop.agents.connectionLock); disconnecting returns the loop to fully local. See Companion setup for the connect and disconnect flow.
Gated by config.desktop.agents, ships off by default. Every desktop project carries this whole AI surface in its source - enabled decides whether it renders and runs, so it is a config change, not a re-scaffold.
agents.enabled | What you get |
|---|---|
true | Two top-level sidebar pages - Chat (/chat) and Schedules (/schedules) - plus the AI configuration tabs in Settings (Models, Tasks, MCP, Integrations) and the right side panel. The app spawns and supervises the local companion daemon that runs every AI action on-device. |
false | No AI pages and no side panel: the app is a plain client shell (login, onboarding, home, account, settings, organization). No provider is ever contacted and no daemon is ever spawned. |
One half is not runtime-toggleable: the bundled daemon. Flipping enabled to true brings back the screens, but the daemon the app bundles lives in apps/companion, and a project generated without AI never received that source. While enabled is false this costs you nothing - stage:companion skips itself and the app packages fine. It is the flip that breaks: with enabled on and no apps/companion, packaging stops at stage:companion with a message telling you to re-run the CLI (init or update) with --ai to add it. Turn AI on through the CLI when you want the daemon, and through config when you only want to gate the surface.
| Field | Default | Description |
|---|---|---|
agents.enabled | false | Whether the desktop AI surface renders and runs. |
agents.userSchedules | true | Whether end-users may author their own background schedules (set false to ship only builder-registered ones). |
agents.sidePanel | { chat: true, terminal: true, default: "chat" } | Which of the side panel's built-in tabs ship and which opens first (see the side panel). |
Where it lives
Chat and Schedules are top-level sidebar pages; the AI configuration surfaces live in Settings. Each renders only when its own flag is on:
- Chat (
/chat) - a persisted, on-device conversation, also reachable as a side-panel tab across the app. - Schedules (
/schedules) - background runs on a cadence (see Scheduled agents). - Models (Settings) - the user's connected coding CLIs and the default model new chats start with. Sourced from the daemon; there is no hosted model registry.
- Tasks (Settings) - a model and reasoning effort per builder-declared task, chosen per device. Appears only when a builder task targets the desktop.
- MCP server (Settings) - an authenticated endpoint external agents use to drive the app on the user's behalf. It is the desktop app's local-first integrations surface, and appears when
config.mcpServeris enabled. - Integrations (Settings) - connect the accounts the assistant's capabilities act on; appears once the app is connected to your backend.
The right side panel carries a Chat tab (the same persisted, on-device conversation) and, when the product ships a companion, a Terminal tab (the user's own CLI, wired to your product); config.desktop.agents.sidePanel chooses which tabs ship and which opens first.
What runs, and where
Every AI action happens on the user's machine, driven by the companion daemon: the user's own CLI, under their own login, confined to a work folder, under a local policy ceiling, and recorded to a local audit log. That confinement, the ceiling, the granted folders, and the audit log are the companion's.
Models
The connected coding CLIs and the default model - sourced from the daemon, no hosted registry.
Tasks
A model and reasoning effort per builder-declared task, chosen per device.
Chat
A persisted, on-device conversation - a full page and a side-panel tab.
Terminal and side panel
Run the user's own CLI in the side panel; choose which tabs ship and which opens first.
Scheduled agents
Background runs that fire on a timer.
Updates and downloads
Background auto-updates via electron-updater, the per-OS update feed, and stable always-latest download links per platform.
Models
The desktop app's models are the user's own installed coding CLIs, connected through the companion daemon - no hosted model registry, no API-key management, no cloud provider catalog.