I pay for five AI coding subscriptions: Claude Max, ChatGPT (which includes Codex), SuperGrok, Google AI Pro, and ClinePass. Each one ships its own terminal agent: Claude Code, Codex CLI, Grok Build, Google’s Antigravity CLI, and the Cline CLI. Add Ollama running local models on the same machine and that’s six ways to run an agent in my terminal.
Until this week, only one of them knew how I work.
Over the past year and a half I’ve built up a serious config layer around Claude Code: 173 skills, 29 custom agents, 9 MCP servers wired to my email, WhatsApp, Telegram, and brokerage, plus a set of global rules covering everything from my writing voice to how credentials get handled. That layer is worth more than any individual model subscription. It’s the difference between an agent that writes code and an agent that ships work the way I ship work.
So I spent an evening making all of them share it. One source of truth, one sync script, and every agent CLI on my machine now loads the same skills, the same rules, the same tools, and the same memory.
The Layer That Actually Matters
Strip away the branding and every agent CLI is the same four things:
- Instructions: a markdown file that shapes behavior (CLAUDE.md, AGENTS.md, GEMINI.md)
- Skills: folders with a SKILL.md that teach the agent a repeatable procedure
- Tools: MCP servers that connect it to email, browsers, APIs, whatever
- Memory: what it knows about you and your ongoing work
In 2026 these converged into de facto standards. AGENTS.md won the instructions war. Anthropic’s SKILL.md format became the cross-vendor skills standard. MCP won tools. It’s convergence with rough edges, since every CLI still has its own paths and size caps, but it means the config you build for one agent is mostly portable to the rest, if you know where each one looks.
Where Each Agent Looks
This was the real research. The compatibility story is much further along than I expected:
Grok Build turned out to be the easy one. xAI shipped it with a full Claude Code compatibility layer: it natively reads CLAUDE.md files, everything in ~/.claude/skills, custom agents, installed plugins, MCP servers from Claude’s own config, even Claude’s permission allowlists. Out of the box it discovered all 173 skills and every MCP server with zero configuration. The one gap: it doesn’t scan Claude’s global ~/.claude/rules directory, so those needed syncing.
The Google leg almost tripped me. Google retired Gemini CLI for AI Pro subscribers on June 18 and replaced it with Antigravity CLI (agy), a closed-source Go binary. It kept the parts that matter here: SKILL.md skills in a global directory, GEMINI.md instruction files, and MCP servers in a dedicated mcp_config.json. One symlink and two generated files cover it.
Codex CLI needs the most translation. It reads AGENTS.md (a config key can add CLAUDE.md as a fallback), but my rules live in separate files, so a script generates one combined AGENTS.md from all of them. Skills load from ~/.agents/skills, and MCP servers register through its own CLI.
Cline reads AGENTS.md from the project and from a global ~/.agents/AGENTS.md, loads SKILL.md skills from ~/.cline/skills, and takes MCP servers in a JSON file. Cline also solves the Ollama question: it has a native Ollama provider, so my local models get the whole config layer through the same harness. No separate tool needed.
The Sync Script
Everything flows from Claude Code’s config as the single source of truth. A 200-line bash script regenerates the rest:
- Builds a combined AGENTS.md (instructions + rules + a pointer to my memory files) for Codex, Antigravity, and Cline
- Splits my rules across three files for Grok, which accepts Agents.md, AGENT.md, and Claude.md as separate global files. Grok’s docs cap each file at 10,000 characters, so a small bin-packing routine keeps every bucket under the documented limit.
- Symlinks skills everywhere they’re not auto-discovered
- Reads Claude’s MCP registry and re-registers each local server with Codex, Antigravity, and Cline
- Drops an AGENTS.md symlink next to every CLAUDE.md in my repos, git-excluded so it never gets committed
Then two pieces of automation so I never think about it again: a Claude Code hook re-runs the sync whenever a rule or skill file changes, and a daily launchd job catches anything edited outside a session.
The Gotchas That Cost Me Time
None of these are in the docs’ quick-start pages:
Codex caps instruction files at 32 KiB by default. My combined file came out at 32,089 bytes, under the cap by exactly 679 bytes. There’s a config key for it (project_doc_max_bytes), but it’s positional TOML: append it to the end of config.toml and it lands inside whatever table happens to be last, and Codex refuses to start. It goes at the top of the file.
Grok’s docs and Grok’s binary disagree about size limits. The bundled README says every instruction file gets truncated at 10,000 characters. When I tested it with a 14KB file and a marker on the last line, the whole thing loaded. I split my rules to fit the documented cap anyway, since I’d rather not depend on undocumented behavior that the next release could change. The general lesson: don’t trust the docs or the binary alone, test what actually loads.
Permissions travel further than you might want. Because Grok reads Claude’s permission allowlists natively, every command I’d pre-approved for Claude was pre-approved for Grok the moment I logged in. At least that’s how it behaved in my setup. Worth an audit before you lean on a second agent.
Hosted OAuth connectors don’t port. My Claude-hosted Notion, Google Calendar, and Drive connectors authenticate through Anthropic, so they stay Claude-only. Every self-hosted MCP server ported fine, including the one that runs my email.
Why Bother
The economics alone justify it: I’m paying for all of these subscriptions anyway, and quota resets mean there’s usually one with headroom. When a provider has an outage or a bad model week, the others pick up with zero re-teaching.
Then there’s routing. Once every agent shares the same config, picking the model becomes a per-task decision that costs nothing. I send hard architectural work to the strongest reasoning model available that day, and mechanical batch edits to something fast and cheap. Anything I’d rather keep off other people’s servers runs on a local model through Ollama, with the same skills and tools as the frontier models. Switching used to mean re-explaining my whole setup. Now it’s a different command in the same terminal.
The benefit I underestimated is cross-model review. Every model has blind spots, and it’s worst at catching its own. A second agent from a different vendor, loaded with identical context, is the cheapest serious reviewer you can get. I had Grok Build and Codex review a draft of this article, each checking the claims about itself: Codex caught a section describing a product Google had retired three weeks earlier, and Grok flagged a claim its own documentation got wrong. Review passes now go to a different model than the one that did the work, for the same reason a developer doesn’t review their own PR.
It also makes model comparisons real. Benchmarks tell you how models perform on someone else’s tasks; identical config means I can run the same job through two agents and judge on my own work instead.
And it’s the same argument I made about not installing the big bundled agents: the durable asset is the middle layer you own. Models rotate. Skills, rules, tools, and memory compound.
The vendors seem to understand this too, which is why the compatibility layers exist at all. xAI reading Claude’s config natively is a statement: they know where the switching costs live. Making that layer portable means every future agent CLI starts with all of my accumulated context on day one.
Related
Leave a Reply