Multi-assistant support

Most teams don't use one AI coding assistant. They use whichever one fits the moment — Claude Code for deep refactors, Codex for quick edits, Gemini for tasks where its long context helps. Different team members have different preferences. The same person might switch tools mid-week.

cix is designed for this reality. One install configures all three major coding assistants to share the same index, the same conventions, and the same behavior.

What is supported today

Claude Code — Anthropic's CLI for Claude. Full feature set, including write-time convention enforcement.
Codex — OpenAI's coding assistant. Full read access to the index and conventions.
Gemini CLI — Google's CLI assistant. Index access and orientation features.

The integration is the same in all three: the assistant gets a focused set of tools for querying the project, with the same query semantics, the same response shape, and the same confidence signals.

Why this matters

Tool choice should not require context choice. If switching assistants means rebuilding your project context from scratch, you stop switching — even when a different tool would be the better fit for the task. cix makes the switch zero-cost from a context standpoint.

Teams with mixed tooling don't fork. A team where half the developers use Claude Code and half use Codex doesn't end up with two separate context systems, two separate convention files, or two separate ways of doing things. Everyone uses the same index. Everyone gets the same behavior.

Vendor risk is bounded. If a vendor changes their pricing, retires a model, or shuts down a product, your project context doesn't go with them. The index is yours. It lives on your machine. It works against any assistant that supports the integration standard.

How the integration works

cix exposes its query layer over the Model Context Protocol (MCP), an open standard several AI coding tools have adopted. MCP defines a small interface for tools to expose capabilities to assistants — query, write, list, that sort of thing. Any assistant that speaks MCP can use the cix capabilities the same way.

What this means in practice:

One install command configures the integration for the assistants you select.
The configuration lives in each assistant's standard config location — no extra layer to learn.
Updates to cix update the integration for all configured assistants.
Adding a new assistant later is a single command, not a rebuild.

What about clients without MCP support?

For now, cix focuses on the assistants that already support MCP — that's where the active ecosystem is and where the integration is robust. If your preferred tool doesn't speak MCP yet, the index and command-line tools still work; you just don't get the in-assistant integration.

As more clients adopt MCP, cix will pick them up. The protocol is open, the integration is small, and we are not in the business of writing custom adapters for closed systems.

Convention enforcement across clients

Convention enforcement — the part of cix that blocks writes that violate your project rules — depends on each client exposing a write hook. Today, this is well-supported in Claude Code; partial in others.

For clients without write hooks:

The conventions still exist as a machine-readable file.
The orientation step still informs the assistant about them.
The validation query still works — the assistant can ask "is this path allowed?" before writing.
Violations surface as warnings the assistant must address, rather than blocked writes.

The honest framing: enforcement is strongest on Claude Code today. The other clients get the index, the conventions, the queries, and the discipline — just with softer enforcement on the write side.

What you get for free

Same index, multiple clients. Index a project once; query it from any configured assistant.
Same conventions, multiple clients. Update your conventions file; every assistant picks up the change.
Same confidence signals. Whether you're using Claude, Codex, or Gemini, you get the same "I don't know this" honesty when the index doesn't have an answer.
Local-first operation. No assistant has to send your code anywhere it wasn't already going to. The index is local to your machine.

Shared-index mode for teams

For teams indexing very large repos, cix supports a shared-index mode where one machine hosts the index and other machines query it remotely. This is opt-in, runs entirely on your infrastructure, and is the right call when:

The repo is large enough that re-indexing on every machine is wasteful.
A central server has more resources than developer laptops.
A team wants a single source of truth for the project's index.

For most teams, the default per-machine setup is simpler and sufficient.

How it works — the architecture this integration sits on top of.
For engineering teams — why team consistency matters.
Limitations — where multi-client parity falls short today.