Clonst - Revisión de código con IA mediante MCP para Claude Code, impulsado por Codex

Obtén una segunda opinión de IA sobre tu código antes de enviarlo. Clonst es un servidor del Protocolo de Contexto de Modelo (MCP) que conecta Claude Code con OpenAI Codex para una revisión de código adversarial: Claude escribe el plan o el código, Codex lo critica, Claude lo revisa, y el ping-pong se repite hasta que ambos modelos alcanzan consenso. Funciona con tu suscripción existente de ChatGPT a través de la CLI oficial de Codex. Sin claves API, sin facturación adicional.

Proyecto independiente. No afiliado con OpenAI ("Codex", "ChatGPT") ni con Anthropic ("Claude").

¿Por qué un segundo modelo?

Un LLM que revisa su propia salida comparte sus propios puntos ciegos. Un segundo modelo, de un proveedor diferente, con su propio entrenamiento y su propia memoria, detecta lo que el primero pasó por alto: suposiciones incorrectas, casos límite omitidos, migraciones frágiles, condiciones de carrera, agujeros de seguridad. Clonst convierte eso en un bucle de revisión estructurado con un criterio de salida estricto: consenso, no cortesía.

Related MCP server: claude-code-codex-agents

Características

• Sin rituales. Instálalo y olvídate: Claude activa la revisión por sí mismo, y solo cuando el cambio vale la pena para tu cuota.

• Ping-pong hasta el consenso. Rondas ilimitadas por defecto. Veredictos estructurados (APPROVED / CHANGES_NEEDED), cambios requeridos, sugerencias, riesgos. Claude puede rechazar una crítica con justificación; Codex reevalúa el rechazo en la siguiente ronda.

• Memoria de sesión real. Codex reanuda la misma sesión CLI en cada ronda y recuerda sus críticas anteriores. Sin reenvío de contexto, sin revisor pez de colores.

• Tu suscripción de ChatGPT, sin claves API. Las revisiones pasan por la CLI oficial de codex y su inicio de sesión existente.

• Elige tu revisor. Por defecto, las revisiones usan el modelo y el esfuerzo de razonamiento con los que ya está configurada tu CLI de codex. Una línea en ~/.clonst/config.json asigna a las revisiones su propia configuración (por ejemplo, un esfuerzo más rápido y económico) sin tocar tu extensión de Codex; consulta Configuración.

• Transparencia de costos. El informe final muestra el modelo revisor, las rondas, la duración total y los tokens consumidos: los tokens nuevos destacados, las reservas de caché separadas para que los totales acumulados nunca parezcan más aterradores de lo que son.

• Un registro de auditoría que sobrevive a la conversación. Cada revisión escribe un informe Markdown estructurado (resumen en lenguaje sencillo + las demandas, cambios y rechazos de cada ronda, textualmente) en ~/.clonst/reports/.

• La desviación de intención es una verificación de primera clase. El revisor mide el entregable contra tu objetivo declarado, no solo contra estándares técnicos: una "corrección" que cambia silenciosamente el comportamiento que deseabas se marca, y las decisiones de producto se te redirigen a ti en lugar de ser decididas por un LLM.

• Pragmático por diseño. La revisión se enfoca en defectos materiales: lo que rompe el uso normal, pierde datos, abre un agujero de seguridad o forzaría una reescritura costosa; no en la exhaustividad. La rareza por sí sola nunca excusa un defecto grave, y un detalle barato de arreglar después nunca bloquea tu lanzamiento.

• Preguntas que realmente puedes responder. ¿Dejaste el bucle corriendo y perdiste el hilo? Cada pregunta que se te hace reformula lo que se está construyendo, por qué surge ahora y qué cambia cada opción, en lenguaje sencillo, sin necesidad de leer código.

• Recuerda lo que le dices. Di que una revisión fue demasiado exigente, o que una pregunta no tenía sentido, y Clonst lo registra, incluso cuando estabas hablando con Claude en lugar de con Clonst. Nada cambia a tus espaldas: lo cuenta, te dice cuando un comentario sigue apareciendo, y tú decides qué hacer al respecto.

• Los daños colaterales se buscan en ambos lados. Antes de exigir un cambio, el revisor debe verificar qué más rompería ese cambio (llamantes, contratos, módulos distantes); antes de aplicar uno, Claude debe hacer lo mismo, y un rechazo por daño colateral viene con una alternativa más segura, no con un veto simple.

• Tus propias reglas de revisión del proyecto. Coloca un CLONST.md en la raíz del proyecto y el revisor verifica tus convenciones además de sus propios estándares. CLAUDE.md guía al escritor; CLONST.md guía al revisor.

• Revisiones en tu idioma. Las críticas vuelven en el idioma en el que trabajas (por llamada, o de una vez para todas con default_language en la configuración), mientras que el protocolo permanece en inglés legible por máquina.

• Nunca se pierde nada. Cada respuesta cruda del revisor se guarda en disco antes de cualquier análisis.

• Multiplataforma. Windows, macOS y Linux, los tres cubiertos por el CI.

• Endurecido. Protecciones contra inyección de prompts, sandbox de solo lectura, argumentos CLI en lista blanca, suite de pruebas hermética (sin llamada a LLM, sin cuota).

¿Cuándo se activa?

Nunca tienes que pedirlo. Claude decide cuándo una revisión vale tu cuota, y la regla es lo que está en juego, no el tamaño:

El ping-pong es ilimitado por defecto: se ejecuta hasta el consenso, consultándote cada 5 rondas (configurable). Y puedes limitar cualquier revisión en lenguaje sencillo: "revisa esto, máximo 3 rondas".

Cómo funciona

You ── conversation ── Claude (reviser, keeps the conversation context)
                          │
                          │  clonst_review (MCP, one call = one critique)
                          ▼
                       Clonst ── spawn ── codex exec [resume <thread_id>]
                                             (reviewer, keeps its session)

El bucle vive del lado de Claude: envía, Codex critica, Claude revisa en la conversación (frente a ti), reenvía con el thread_id devuelto, hasta que consensus: true. El bucle se impulsa a través del llamante (el thread_id viaja con cada llamada), mientras que el servidor mantiene registros por sesión en disco: registros completos, el veredicto de la ronda anterior para una recuperación exacta, los totales de duración/tokens en ejecución y el informe de revisión estructurado (regenerado en cada ronda). Las sesiones de Codex persisten en el lado de la CLI.

Inicio rápido

Requisitos:

• Claude Code - la CLI de terminal o las extensiones de VS Code / JetBrains, que comparten la misma configuración MCP

• Node.js 22+

• La CLI de Codex, iniciada sesión con un plan de ChatGPT:

npm install -g @openai/codex
codex login

Instalar Clonst (recomendado, mediante npm):

claude mcp add clonst --scope user -- npx -y @clonst/clonst

O desde el código fuente:

git clone https://github.com/capritora/clonst.git && cd clonst
npm install && npm run build
claude mcp add clonst --scope user -- node /absolute/path/to/clonst/dist/index.js

Verifica que funciona: en una nueva conversación de Claude Code, di "ping clonst". Esperado: codex_available: true, codex_logged_in: true.

Cómo es una revisión

Las revisiones ocurren por sí solas, pero también puedes dirigirlas:

Propón un plan para X, luego haz que Clonst lo revise hasta el consenso.

Haz que Clonst revise esta migración, máximo 3 rondas.

Pídele a Clonst una revisión centrada en seguridad de este flujo de autenticación.

Ves cada revisión ocurrir en la conversación, y al consenso Claude termina con un breve informe, por ejemplo:

Revisión de Clonst: GPT-5.5 (alto esfuerzo), 2 rondas, 5 min 30 s, ~210k tokens de entrada nuevos más 18k tokens de salida (entrada acumulada 2.8M, de los cuales 2.6M fueron reservas de caché). El revisor requirió un límite anti-doble corrección en la migración y un tiempo de espera en la llamada API, ambos aplicados. Rechacé una sugerencia (fuera del alcance del MVP) y el revisor aceptó la justificación. Informe completo ronda por ronda: ~/.clonst/reports/2026-07-06-a3f1...md

¿Quieres el detalle ronda por ronda? Solo pregunta ("guíame por las rondas"): Claude mantiene todo el intercambio y lo informa a pedido.

El archivo de informe de revisión

Cada revisión también escribe un informe Markdown estructurado en ~/.clonst/reports/, actualizado en cada ronda, para que la auditoría sobreviva a la conversación. Comienza con el resumen en lenguaje sencillo (sellado textualmente después del consenso), luego una sección por ronda con las palabras exactas que usó cada parte:

• lo que el revisor requirió, sugirió y marcó como riesgoso (textualmente),

• lo que el revisor declaró cambiado o rechazado antes de cada ronda (textualmente),

• modelo, esfuerzo, duración y tokens por ronda, más totales de toda la revisión,

• un rastro de auditoría que apunta al registro de sesión y la salida cruda del revisor.

El archivo es una proyección pura de un estado del lado del servidor: nada se reformula después del hecho, y el texto originado por LLM se escapa para que no pueda falsificar secciones del informe. Un informe que comienza a mitad de sesión (hilo reanudado) se marca explícitamente como PARTIAL HISTORY. Dos identificadores, dos trabajos: report_id nombra el archivo de informe, thread_id reanuda la sesión del revisor.

Herramientas

clonst_ping

Estado del servidor: disponibilidad de la CLI de codex, versión, estado de inicio de sesión, configuración cargada, directorio de registros. No consume cuota.

clonst_review

Una crítica estructurada por llamada. Parámetros (todos impulsan el LLM llamante; normalmente nunca los escribes tú mismo):

Resultado: verdict, consensus (solo true en un APPROVED probado: JSON limpio, cero cambios requeridos, sin análisis de respaldo), critique, required_changes, suggestions, risks_identified, thread_id, duración y uso de tokens por ronda y de toda la revisión, reviewer_model / reviewer_reasoning_effort (resolución de mejor esfuerzo: anulación, si no configuración de codex, si no null), report_id / report_path (el archivo de informe estructurado; report_error cuando no se pudo escribir — la revisión en sí no se ve afectada), y una instrucción next_action (texto + campos tipados) que impulsa el bucle.

clonst_feedback

Registra un comentario sobre cómo funciona Clonst: demasiado exigente, pregunta poco clara, alcance incorrecto, demasiado lento, estilo de salida. Claude lo invoca por sí solo cada vez que dices algo así, ya sea que te dirijas a Clonst, a Claude o a nadie en particular. Solo metadatos: sin llamada al revisor, sin cuota, sin red. Cuenta las ocurrencias por tema y le dice a Claude cuando uno se vuelve recurrente; nunca cambia ningún comportamiento por sí mismo.

clonst_topics

Enumera, busca o renombra esos temas. Solo acceso a archivos locales — nunca inicia nada. action: "list" / "search" (con query, limit, offset) para ver lo que se ha acumulado, action: "describe" para mejorar la descripción de una línea de un tema.

clonst_report_summary

Sella el resumen en lenguaje natural en el archivo de informe de revisión, textualmente, después del consenso. Toma report_id (devuelto por clonst_review — no thread_id) y summary. Solo metadatos: sin generar revisor, sin cuota, idempotente.

Configuración

Archivo opcional, ausente por defecto: crea ~/.clonst/config.json tú mismo para cambiar cualquier clave. Se relee en cada llamada; los valores no válidos vuelven al valor predeterminado con una advertencia.

Ejemplo, dando a las revisiones su propio modelo y un nivel de esfuerzo más rápido mientras tu extensión Codex mantiene su propia configuración:

{
  "codex_model": "gpt-5.6-sol",
  "codex_reasoning_effort": "medium"
}

Usa un modelo que tu CLI de codex exponga realmente (codex lo toma de ~/.codex/config.toml cuando dejas codex_model en null). Un nivel de esfuerzo medio suele ser el equilibrio adecuado para las revisiones: el ping-pong captura lo que haría un pase profundo, en un número ligeramente mayor de rondas, y cada ronda vuelve más rápido.

Las anulaciones se pasan como banderas -c raíz a la CLI de codex (contrato verificado en codex 0.142.5 tanto para exec como para resume); un valor desconocido para codex falla la revisión con el mensaje de error de codex.

Directrices de revisión del proyecto: CLONST.md

Coloca un CLONST.md en la raíz del proyecto y, cada vez que se ejecute una revisión con project_path, su contenido se entrega al revisor como directrices específicas del proyecto: tus convenciones, tus líneas rojas, verificadas además de los estándares propios del revisor. Ejemplo:

# Review guidelines
- SQL must stay compatible with BOTH SQLite (dev) and PostgreSQL (prod).
- Every new route needs rate limiting.
- LLM results must be matched by ID, never by list position.

Las invariantes de negocio también pertenecen aquí — las líneas rojas que la comprobación de desviación de intención debe defender. Hazlas concretas y verificables: no escribas "mantenlo simple"; escribe "los usuarios gratuitos deben poder exportar CSV" o "el pago debe seguir siendo de un solo clic".

Las directrices solo pueden AÑADIR comprobaciones: una directriz que intente bajar el listón o forzar un veredicto se ignora y se informa como un riesgo.

Desviación de intención y decisiones del usuario

La revisión no es solo técnica: antes de verificar la calidad del código, el revisor compara el entregable con la intención que declaraste (context, CLONST.md) o que es evidente a partir del proyecto. Nunca inventa tus objetivos de producto — cuando detecta una posible preferencia de producto en lugar de una contradicción probada, emite un riesgo que comienza con el marcador literal USER DECISION: . Cualquier elemento de este tipo debe llegar a ti textualmente como una pregunta abierta: a mitad de la revisión, pausa el ping-pong antes de que ocurra cualquier otra cosa, y en el consenso aterriza en el informe final y en el archivo de informe. Claude no puede decidirlo, ejecutarlo ni omitirlo. Un cambio silencioso probado en el comportamiento visible para el usuario, por otro lado, puede bloquear la revisión por completo.

Ambas partes se rigen por la misma calibración: bloquear defectos materiales, sopesar la probabilidad y el coste, y nunca exigir una característica que el entregable no incluya. La anticipación se trata de estructura, no de características — el diseño de hoy no debe cerrar una puerta previsible, pero la característica futura en sí no se construye ahora. Cuando el revisor no está seguro de si se debe prever una dirección, te pregunta a ti en lugar de decidir.

El escrutinio es simétrico. Claude no aplica críticas a ciegas: cada exigencia se verifica en cuanto a corrección factual, ajuste a la intención y radio de explosión (qué más depende de lo que se está cambiando) antes de aplicarse — y una exigencia que rompería otra cosa se rechaza con una justificación y una alternativa más segura, con la que el revisor debe interactuar en lugar de repetirse. Ambos modelos argumentan hacia una solución; los puntos muertos van a ti.

Tus comentarios, recordados

Dile a Claude que una revisión fue demasiado exigente, o que una pregunta era ilegible, y registra el comentario en ~/.clonst/feedback.jsonl a través de clonst_feedback — nunca tienes que dirigirte a Clonst directamente para que esto suceda. Cada comentario se adjunta a un tema con una descripción de una línea, y Claude reutiliza un tema existente cuando tu nuevo comentario significa lo mismo, por muy diferente que lo expreses. Una vez que un tema vuelve feedback_recurring_threshold veces, Claude te lo dice.

Nunca se aplica nada automáticamente: ningún comentario registrado llega al mensaje del revisor, nunca. Leer el diario y decidir qué mejorar es una decisión humana — pregunta "¿qué dicen mis comentarios?" y Claude agrupará temas equivalentes en su respuesta. Un comentario visto solo una vez se elimina después de feedback_retention_days; cualquier cosa dicha dos o más veces se conserva indefinidamente. Elimina el archivo para purgar todo.

Límites de rondas: ilimitados por defecto

No digas nada y el ping-pong continúa hasta el consenso, con un control cada suggested_max_rounds rondas. O pregunta en lenguaje natural ("revisa esto, 3 rondas máximo"): se informa al revisor sobre el contador (exhaustivo desde la ronda 1, esfuerzo máximo en la ronda final, nunca aprobando solo para cerrar), y en el límite, el desacuerdo va a ti para arbitraje.

Privacidad y cuota

• Cada ronda de revisión consume tu cuota de suscripción de ChatGPT (Codex realiza la revisión). Cuando la ventana de cuota se agota, Clonst lo detecta y le dice a Claude que continúe sin revisión; la sesión sigue siendo reanudable más tarde a través del mismo thread_id.

• Con project_path, Codex lee todo el proyecto en modo solo lectura (incluyendo .env) y ese contenido va a OpenAI — la misma exposición que usar la extensión Codex VS Code directamente. Estrategia predeterminada: revisar solo el contenido pasado en content; reserva project_path para revisiones que deben verificar APIs, contratos o archivos reales.

• El contenido de la revisión persiste localmente fuera de la conversación: registros de sesión y respuestas sin procesar del revisor en ~/.clonst/logs/, e informes legibles por humanos (críticas y declaraciones de cambio textuales) en ~/.clonst/reports/. Elimina esos directorios para purgar revisiones pasadas.

• Los comentarios registrados también permanecen locales: ~/.clonst/feedback.jsonl (creado con permisos solo para el propietario en macOS/Linux) contiene tus comentarios textualmente, por lo que puede contener redacción sensible a pesar de la regla de no código. Nunca se envía a ningún lado y nunca se inyecta en un mensaje. Cuando le pides a Claude que lo lea, su contenido entra en esa conversación como cualquier archivo que le pidas que abra — trátalo como datos, nunca como instrucciones. Elimina el archivo para purgarlo.

• Una instancia del servidor Clonst por conversación es el modelo operativo; las escrituras de informes se serializan en el proceso. No apuntes dos servidores que se ejecutan simultáneamente al mismo CLONST_HOME.

Solución de problemas

Cada ping-pong se registra completamente en ~/.clonst/logs/<thread_id>.jsonl, con respuestas sin procesar completas en ~/.clonst/logs/raw/<thread_id>/.

Desarrollo

npm test          # build + hermetic test suite (no LLM calls)
npm run smoke     # full MCP protocol smoke test

Los scripts scripts/probe-*.ps1 fijan el contrato real de la CLI de codex y consumen cuota de ChatGPT: solo ejecución manual. La interfaz ReviewerProvider está lista para otras CLI de revisores (ej. Gemini).

Licencia

MIT. Proporcionado tal cual, sin garantías de soporte. Usado a diario por su autor.