I Run My Second Brain on Four AI CLIs

Claude Code, Codex, Gemini, OpenCode. One codebase, the same 45 commands. Your AI knowledge setup should not be hostage to one company's tool.

Jun 23, 2026

TL;DR
Most people build their AI second brain inside one vendor's CLI, then they are married to it. I build mine once and it runs on four: Claude Code, Codex, Gemini, and OpenCode, even on local open models. Same vault, same commands, no lock-in. Here is how it works and why it matters more than which model is best this month.

Here is a question nobody building an AI second brain asks until it is too late: what happens when the tool you built it inside changes?

Most people pour months into a setup that lives inside one CLI. Every command, every workflow, every habit is wired to Claude Code, or to whatever they started with. It feels great. Until that tool raises its price, changes a policy, ships a breaking update, or you simply want to try another one. Then you find out your second brain was never really yours. It was renting space inside someone else’s product.

I did not want that. So my second brain runs on four CLIs, from one codebase. Here is the idea and the build.

The brain is the files. The CLI is just the hands.

The whole thing rests on one separation most people never make.

Your knowledge is a folder of plain markdown. That is the brain. It does not care what reads it. I made the full case for keeping an AI’s memory in plain folders in its own post. The CLI, Claude Code or anything else, is just the pair of hands that reads, writes, and reasons over those files. Hands are replaceable. The brain should not be.

Once you see it that way, locking your brain to one set of hands looks like a mistake. So I stopped doing it.

One codebase, four builds

The commands are written once. A build step turns that one codebase into a package for each CLI.

I run a build script and it produces a version for Claude Code, Codex, Gemini, and OpenCode. Each build gets its own dispatcher file (the CLIs expect different names) and an auto-generated routing table that maps plain-English triggers to the right command. The vault behaves identically across all four. The only differences are the install path and the wiring underneath.

It is 45 commands in total. Four of them are Claude-Code-only (they touch Google Calendar), so the other three CLIs ship 40. Beyond that, same brain, same behavior, four front doors.

You are not locked to a model either

This is the part that goes deeper than CLIs.

Because the builds are plain instruction files, not code tied to one provider, they run on whatever model the host CLI points at. The OpenCode build will happily run on an open model like Nous Hermes through OpenRouter. Point it at a small model running locally through Ollama, and nothing leaves your machine. Same commands, same vault, your choice of brain behind the hands.

So the lock-in disappears on both axes. Not chained to one company’s CLI, and not chained to one company’s model.

Why this matters more than the model race

Everyone is arguing about which model is smartest this month. That argument resets every few weeks. The thing that actually protects you is whether your setup survives the churn.

CLIs and models in 2026 change fast. Prices move, terms change, favorites get deprecated, new ones appear. If your knowledge system is welded to one of them, every one of those changes is your problem. If your knowledge system is plain files plus commands that build for anything, the churn is just Tuesday. You switch the hands and keep the brain.

That portability is the real moat. Not the model. The model is rented. The files are yours.

Where it breaks

I am not going to pretend this is free.

Maintaining four builds is real overhead. Every time I add a command I make sure it builds cleanly for all four, and a few features genuinely cannot be portable (the calendar commands lean on Claude Code specifics). If you only ever use one CLI and never plan to switch, you do not need this. Single-CLI is simpler, and simpler is correct until portability actually buys you something.

The honest rule: build for one CLI until the day a price change or a policy or a shiny new tool makes you wish you could move. The people who set it up to be portable before that day are the ones who move in an afternoon instead of a month.

If you want to do this

Start with the separation, even if you never build for four CLIs. Keep your knowledge as plain markdown in git, and keep your commands as plain instruction files, not code bolted to one provider. That alone makes you portable.

The full setup is open source. The obsidian-second-brain skill ships the build script and all four targets: one codebase, four CLIs, 45 commands, MIT licensed. Clone it, run the build for your CLI, or read it to copy the pattern.

I am not theorizing. This is the system I built for myself and then watched 2,700 developers clone. It runs on four CLIs today because I refuse to let one company own my second brain.

Frequently asked questions

Can one AI second brain run on Claude Code, Codex, and Gemini at once?
Yes. You write the commands once and a build step produces a package for each CLI, with its own dispatcher file and a routing table. The vault behaves the same on all of them. Mine runs on Claude Code, Codex CLI, Gemini CLI, and OpenCode.

Why not just pick one CLI and stick with it?
You can, and if you never plan to switch, that is simpler. The reason to go portable is that CLIs and models change fast in 2026. If your setup is welded to one, every price or policy change is your problem. Portable means you switch tools in an afternoon, not a month.

Is it locked to one AI provider’s model?
No. Because the builds are plain instruction files, they run on whatever model the host CLI uses, including open models like Nous Hermes via OpenRouter or a local model through Ollama, so nothing has to leave your machine.

Do all the commands work on every CLI?
Almost. It is 45 commands total; four that touch Google Calendar are Claude-Code-only, so the other CLIs ship 40. Everything else is identical across the four.

What is the actual brain made of?
Plain markdown files in git. No database, no app. That is the whole point: the files are the brain and they do not care which CLI reads them, so they survive any tool change.

Key takeaways

Your AI knowledge lives in plain files. The CLI is just the hands that read and write them, and hands should be swappable.
One codebase builds for four CLIs (Claude Code, Codex, Gemini, OpenCode) with the same 45 commands and identical vault behavior.
Because the builds are plain instruction files, you are not locked to one model either, including open and local models for privacy.
The real protection in a fast-churning 2026 is portability, not picking the smartest model this month.
Single-CLI is simpler and correct until a price or policy change makes you wish you could move. Set up portability before that day.
The files are yours. The model and the CLI are rented.

About the author

Eugeniu Ghelbur is an AI Automation Engineer at Single Grain, where he builds production AI systems for marketing and sales workflows. He ships open-source Claude Code skills and writes about AI knowledge management at theaioperator.io. The obsidian-second-brain skill described here is live on GitHub at github.com/eugeniughelbur/obsidian-second-brain, where it has been starred by over 2,700 developers.