Gemini Plugin For Claude Code

[sakibsadmanshajib]

I've been experimenting with multi-agent coding workflows for a while now — using Claude Code as the orchestrator, with Codex and Gemini CLI as specialized sub-agents.

The idea is simple: each model has different strengths.

• Claude — the engineering lead. Smart orchestration, deep reasoning.
• Codex — focused fixes, fast iteration.
• Gemini — 1M token context window for whole-codebase investigation.

I started with custom skills to glue them together. It worked, but it was fragile. Then OpenAI released codex-plugin-cc — an official Claude Code plugin that delegates tasks to Codex through their App Server Protocol. That made the Codex side clean and proper.

I wanted the same thing for Gemini.

So last night, I ported codex-plugin-cc to Gemini CLI. Built it in a few hours using Claude Code itself (which felt appropriately meta). Instead of Codex's App Server Protocol, it uses Gemini's ACP (Agent Client Protocol) — JSON-RPC over stdio with a persistent broker.

Same slash commands:
/gemini:review — Gemini reviews your code
/gemini:adversarial-review — challenges your design decisions
/gemini:rescue — delegates tasks to Gemini

It's a 1:1 port right now. The command interface, job tracking, state persistence, and review logic are all faithful to the original. The only thing that changed is the transport layer. I plan to expand it with Gemini-specific features later.

If you use Claude Code and Gemini CLI, give it a try:
https://github.com/sakibsadmanshajib/gemini-plugin-cc

Feedback, issues, and PRs are all welcome. This is early — I want to know what breaks and what's missing.

#ClaudeCode #GeminiCLI #AI #DevTools #OpenSource #MultiAgent #SoftwareEngineering

[Amar07Singh]

Hey @sakibsadmanshajib — how is Claude Code scaling on your gemini-cli repo?

Are you hitting those weird context walls where it starts losing track of files, or is it staying snappy?

[aniruddhaadak80]

Hey there. Thanks for sharing this.

Building integrations on top of the CLI is exactly what we love to see. This looks like a really solid approach.

If you have a GitHub repository for this project, definitely drop the link here.

[ofekron]

Maintainer disclosure: I build Better Agent, a local workspace that supervises these same provider-native CLIs.

A 1:1 command port is a useful starting point, but I would avoid treating Codex App Server and Gemini ACP as semantically interchangeable beneath it. The failure cases that mattered most in our implementation were:

• Persist three separate identities: the orchestration job, Gemini ACP session, and broker process instance. Never infer one from another.
• Append provider events durably before publishing job updates, and give reconnecting callers a cursor so a Claude restart does not lose Gemini output.
• Keep cancellation requested, process exit, protocol error, and successful completion as distinct terminal paths. A closed stdio stream is not proof of success.
• Negotiate capabilities and event shapes instead of assuming every Codex review/tool update has a Gemini equivalent.
• Let the broker own child-process cleanup. The slash-command caller or UI may disappear while the delegated session remains valid.

The test matrix I would prioritize is: Claude restarts while Gemini runs; broker restarts after emitting but before acknowledging an event; duplicate resume; cancel during a tool call; and an unsupported ACP capability. Those expose whether “persistent” means durable state or only a long-lived process.

License note for the linked implementation reference: Better Agent is source-available and free for non-commercial use; commercial use requires separate permission.