Desktop app
The desktop app and the daemon it carries — sign-in, the local daemon, which settings live here rather than in the web app, and what is not yet qualified.
Kairoku is three pieces that share one account. The web app at app.kairoku.io holds projects, releases, documents and the Floor. The desktop app is where you chat with named Teammates and where machine-local integrations live. kairokud is the daemon the desktop app installs and talks to on your machine: it keeps the vault, runs the scheduler, and is the process an event can wake. This page is the desktop half, so a reader knows which surface a feature is on before looking for it.
Which surface holds what
| You want to | Go to |
|---|---|
| Write plans, file documents, run a phase, watch the Floor | Web app |
| Connect GitHub or GitLab so plans and the Overview can read a repository | Web app — Connections |
| Mint MCP tokens, register a runner machine, see its daemons | Web app — Settings → Developers |
| Chat with a Teammate, create one, grant it tools | Desktop app — Teammates |
| Connect Slack, install a catalog connector, store a token in the vault | Desktop app — Settings → Connections |
| Create a cron, signed-webhook or forge automation | Desktop app — Settings → Connections → Automations. The web app's Settings → Developers → Automations keeps a separate catalog on your account, and nothing fires from it in this release — see Automations |
| Save a playbook; draw a workflow graph | Desktop Workflow catalog for the playbooks the daemon runs; the web app's Settings → Developers → Workflows graph builder saves to a separate catalog on your account, and nothing executes a web run in this release — see Workflows |
The web app's Settings → Agents page is a different thing from a desktop Teammate: those are the app's own chat assistants with MCP tools, and they do not carry Slack grants or bind to a daemon session. Glossary keeps the nouns apart.
Native Mission Control read and native action parity are separate claims, and neither is qualified below. A link into the web app is not a native control.
Sign in and the local daemon
Sign in with the same account as the web app. On launch the desktop app starts the daemon it bundles and reaches it over a local socket under ~/.kairoku/daemon/. The desktop app configures; the daemon owns the data — installations, credentials, Teammates, automations and playbooks survive a desktop restart as long as the daemon keeps its directory.
The bundled daemon is pinned by version: a packaged desktop build runs exactly the kairokud it shipped with. To point the app at a daemon you built yourself — a newer kairokud from source, for example — set KAIROKUD_SOCKET to that daemon's socket path in the environment the app launches from. The app then connects to your daemon instead of starting its sidecar.
kairokud is not kairoku daemon. The CLI's kairoku daemon is the orchestration runner that claims Floor runs from the web app; kairokud is the desktop daemon on this page. They are two programs and they do not talk to each other — though an installed kairokud can itself be linked to the app as a runner with kairoku setup --daemon --link. See kairokud as a runner.
Settings → Connections
One tab gathers everything that touches a credential or an external system on this machine:
- Accounts — the GitHub sign-in (and Linear and Sentry, where those surfaces are enabled).
- Slack — the Slack card: install, authorize, and the masked stored token. See Slack.
- Integration catalog — curated connectors the daemon advertises; install with a token or PAT when the entry requires one. See Integration catalog.
- Automations — cron, signed webhook and forge-event triggers. See Automations.
- Workflow catalog — saved, parameterized playbooks over the Solo and Build-and-verify recipes. See Workflows.
- MCP Servers — MCP servers the chat can call.
Secrets pasted into any of these go to the daemon once and are stored encrypted in its vault; the UI never renders a stored value back.
Teammates and the Crew
Teammates are not under Settings. The chat sidebar has a Teammates panel above the thread list; the collective is the Crew. Creating one there, binding a chat to it, and granting it Slack tools are covered on Teammates.
Where the daemon keeps things
| Path | Holds |
|---|---|
~/.kairoku/daemon/ | The daemon's database, socket, and .secrets.json (mode 600) — the vault master key and other daemon secrets |
<repo>/.kairoku/ | Per-repository files the daemon reads: specialists/, attachments/ |
KAIROKUD_SECRETS_FILE moves the secrets file. The vault is file-backed — the master key is not in the OS keychain — so back that directory up with the same care as a password manager export, and never commit it.
What is not qualified
The desktop app has no native Mission Control actions. A configured web link, including Open in web, hands you to the web app; that is not native action parity, and this page does not describe operator, team, or release controls because those controls are not in the desktop app.
Turning the desktop account UI off is meant to be a client rollback only — it must not stop an enrolled daemon or cancel approved work — but that has not been observed. Closing or quitting the desktop app is not evidence that the daemon kept running.
None of the following is qualified. Stated because "not yet checked" and "checked and fine" look the same unless one of them says so.
- Human sign-in is not qualified. No sign-in walk was performed.
- Linux is not qualified.
- Electron quit is not qualified. Unit mocks, browser component tests and screenshots do not prove main-process quit, preload, or secure storage.
- Secure storage is not qualified.
- Live native ticket mint is not qualified.
- Native action parity is not claimed.
Daemon continuity after quit, restart recovery, sign-out, and a real secure-store failure remain pending a human walk of the desktop app on each claimed platform. Human sign-in, Manual and Flow verification, and a Done transition remain human gates.