Agent-readable docs index: /llms.txt. Full docs in one file: /llms-full.txt. Download /docs.zip to grep all markdown files locally.

Access Control

Kimaki checks Discord permissions before it handles any message, slash command, or button, so only trusted people can run agents on your machine. You control access with roles.

Who can trigger Kimaki

A user needs one of these to use the bot:
  • Server Owner
  • Administrator permission
  • Manage Server permission
  • a role named "Kimaki" (case-insensitive)
Messages from anyone else are ignored. Slash commands and buttons reply with You do not have permission to use Kimaki.
message ──▶ has "no-kimaki" role? ── yes ──▶ ignore │ no ▼ Owner / Admin / Manage Server / "Kimaki" role? │ yes │ no ▼ ▼ handle message ignore
The "Kimaki" role is the recommended way to grant team access: create a role named Kimaki and assign it to trusted members. No elevated Discord permissions required.

Blocking users

Create a role named "no-kimaki" (case-insensitive) to block specific users, even server owners. This is useful in shared servers to prevent accidental triggers from people who otherwise have admin rights.

Provider logins need an admin

/login and /transcription-key store secrets for the whole bot. Only the server owner or a member with Administrator can use them. The "Kimaki" role and Manage Server are not enough.
Use a dedicated Discord server for your agents. It keeps coding sessions isolated and gives you full control over who has the Kimaki role.

Other bots

Messages from other Discord bots are always ignored, even when the bot has the "Kimaki" role. To start or continue sessions from scripts, CI, or other agents, use kimaki send instead.

Every message in a project channel starts a session

There is no mention mode: any message from an allowed user in a project channel starts a new thread and session. Inside a thread, only threads with a Kimaki session are handled. Keep chat that is not for the agent in channels that are not project channels.