Migrate from OpenClaw to open-source Kortix

What carries over, and what changes

Both tools keep your work as plain files, and they put those files in different places. OpenClaw keeps everything on one machine: memory and preferences in the agent's workspace, skills as folders that each hold a SKILL.md, and channel plugins on the Gateway (OpenClaw memory overview, OpenClaw skills). Kortix is the open-source AI Operating System, and it holds the same kinds of files in one git repo you own, versioned and diffable like code (Kortix docs).

Two shifts matter before you start. Channel plugins become connector accounts, and connector credentials are brokered server-side and never enter the machine. The runtime changes shape too: instead of one Gateway serving every conversation, each Kortix session gets its own isolated sandbox on its own branch (Kortix on GitHub).

The migration, step by step

Every command runs in the Kortix CLI on macOS or Linux; there is no Windows binary yet (Kortix CLI).

1. Install the CLI and sign in

curl -fsSL https://kortix.com/install | bash downloads a prebuilt binary, and kortix login opens a browser, signs you in, and sets your account and a default project.

2. Create the project repo

kortix init my-company scaffolds a directory with a kortix.yaml manifest and starter agent and skill folders. Run kortix ship inside it: the first run creates the cloud project and pushes the repo, and later runs push your local changes. To bind a repo folder you already have to a project you created, run kortix projects link <project-id>. To run the platform on your own hardware after the move, kortix self-host start brings up the stack, and the self-hosting guide covers it.

3. Move skills, agents, and memory

• Skills. A Kortix skill is skills/<name>/SKILL.md, loaded on demand when an agent needs it. OpenClaw skills have the same shape, so the work is copying folders into skills/ and allowing each agent the skills it may load through the agent's block in kortix.yaml.
• Agents. An OpenClaw persona becomes two parts. The behavior is agents/<name>.md, an OpenCode agent file whose frontmatter sets the model and mode and whose body is the system prompt. The governance is the agent's block in kortix.yaml, which lists the connectors, secrets, skills, and permissions it may touch. Set your everyday agent as default so sessions start with it.
• Memory. OpenClaw keeps MEMORY.md for durable facts, USER.md for preferences, and dated notes under memory/. Copy MEMORY.md and USER.md into Kortix's memory/ directory, and bring the daily notes that still matter. After the move, an agent's edits to memory land through review like any other change.

4. Reconnect channels and bring the models across

• Connectors. Declare each service in kortix.yaml, or pick it from the managed catalog, then authorize an account. The catalog covers 3,000+ apps in a click, plus MCP, OpenAPI, Postman, GraphQL and raw HTTP. Connector credentials are brokered server-side and never enter the machine. Slack and Microsoft Teams are live. Email is experimental, per project.
• Models. On the project's model settings, add a key. Any model provider with your own keys. Or the ChatGPT plan you already pay for. Or sign in with your OpenCode Console account for OpenCode Zen and Go.

5. Recreate scheduled tasks as triggers

An OpenClaw scheduled task becomes a cron or webhook trigger, defined in kortix.yaml. The CLI writes the entry for you:

kortix triggers add daily-digest --type cron --cron "0 0 9 * * 1-5" --timezone America/Los_Angeles --prompt "Summarize yesterday's activity and save it as a daily note."

Run kortix ship to push it, then kortix triggers ls to confirm it is live. A webhook trigger signs its requests with a secret you set with kortix secrets set WEBHOOK_SECRET=<value> (Kortix triggers).

6. Run the first session

kortix sessions new --prompt "Summarize this week's support tickets" --wait

The session runs in its own isolated sandbox on its own branch. Attach to it with kortix sessions chat, or watch from the web app. What it produces is a branch and a change request, not a live edit.

How work lands behind the review gate

In OpenClaw, tools run on the host for the main session unless you configure sandboxing, so a change can take effect directly (OpenClaw repository). Kortix inserts a gate. Every session works on its own branch, and when the agent finishes it opens a change request. Session work reaches main through a change request, merge is default-deny for agents, and a session can never merge a change request it opened itself. Review runs from the terminal:

kortix cr ls
kortix cr diff 1
kortix cr merge 1

The agent opens the request and stops, so what lands on the default branch is a diff you read and approved (Kortix quickstart).