Organizations

Every project belongs to an owner, and an owner is either a person or an organization. That one value — the project's owner_id — is what every query in the app and every one of the fifteen MCP tools scopes by. There are no permission tiers of Kairoku's own: membership and admin rights live in the organization itself, and the app reads them rather than duplicating them.

A personal workspace is not a lesser case of an organization. It is the owner you get when no organization is active, and it is what every project created before organizations existed still belongs to.

Switching context

The switcher in the app's sidebar changes which owner is active. Switching re-scopes the whole app on the next request — projects, releases, documents, activity, settings — and lands you back at the workspace root rather than deep-linking, because the page you were on may not exist in the context you moved to.

Nothing is copied or merged by switching. Your personal projects are simply not the organization's, and the organization's are not yours.

What a team shares

Inside an organization, the things you configure in Settings belong to the organization rather than to you: the GitHub, GitLab and Atlassian connections under Integrations, and the MCP tokens. Two sections exist only there: Workspace, for the organization's name and details, and Members. In personal context the Settings menu leaves them out.

The practical consequence is worth stating plainly. A token you mint while an organization is active is a team credential, and a Jira connection you attach there is the connection every member's pushes go through. In personal context nothing changes from how it behaved before organizations: what you configure is yours.

Moving a project between workspaces

A project can be moved from your personal workspace into an organization you administer, or back out of one. The project's Settings → Danger zone → Transfer project row has a Transfer button; it opens a Move to list of the workspaces available to you, and Move project asks you to confirm before anything moves. Releases, documents, plan, sync mappings and history move with the project.

Three things about the move are deliberate:

• You must be an admin of the organization side, whichever side that is. Moving a project out of an organization is as much an admin act as moving one in.
• Organization to organization is not a single step. Move the project to your personal workspace first, then into the other organization.
• Nothing is auto-renamed. If the destination already has a project using the same slug, the move is refused and tells you so. A slug lives in URLs and in sync mappings, so renaming one silently to make a move succeed would be a second, unasked-for change hidden inside the first.

Agent access

Which workspace an agent sees follows the same owner model, and the two credential types reach it differently.

A personal access token carries its owner permanently: the context that was active when you minted it. Mint it with an organization active and it is an organization credential for the rest of its life; mint it personally and it stays personal. Switching context in the app afterwards does not re-point an existing token.

An OAuth browser sign-in carries a person rather than a context, so the owner is resolved from that person's memberships: no organizations resolves to the personal workspace, exactly one resolves to that organization, and two or more is refused outright rather than guessed. If you belong to more than one organization, use a personal access token minted in the one you mean to work in.

The MCP page covers both credentials in full, including why the refusal is a refusal rather than a fallback.