Intenté reproducir el caso OpenClaw en Claude Code: mi resultado contradice el post viral
Publiqué una hipótesis demasiado fuerte.
El post anterior afirmaba que Claude Code rechazaba commits con OpenClaw y lo leía como una señal clara de alignment no documentado en modo agente. Después intenté reproducirlo mejor, con un repo público y una matriz mínima, y el dato no sostiene esa versión.
No voy a maquillar eso.
El resultado correcto es más incómodo, pero también más útil: no pude reproducir el bloqueo en Claude Code 2.1.126.
Repo del repro:
https://github.com/JuanTorchia/claude-openclaw-commit-matrix
Reporte de corrida:
Qué decía el claim original
El claim fuerte que circuló no era solamente "un commit subject con OpenClaw falla".
La versión más interesante era esta: si openclaw.inbound_meta.v1 aparecía en el historial Git, luego Claude Code podía bloquear o redirigir billing al correr algo tan simple como:
claude -p "hi"Eso importa porque cambia el diagnóstico. Una cosa es un filtro torpe sobre el mensaje de commit. Otra cosa mucho más grave sería un sistema que inspecciona el historial del repo y cambia el comportamiento de Claude Code por una marca previa.
Mi post anterior se fue demasiado rápido hacia la segunda lectura sin tener un repro suficientemente limpio.
Ese fue el error.
Qué probé yo
Armé un repo público dedicado al caso:
https://github.com/JuanTorchia/claude-openclaw-commit-matrix
La idea era sacar el experimento de mi repo real y reducirlo a algo que cualquiera pudiera mirar:
- un repo nuevo;
- commits controlados;
- prompts simples;
- estado antes/después;
- versión exacta de Claude Code;
- reporte guardado en el repo.
La corrida que estoy citando es esta:
Versión probada:
Claude Code 2.1.126Probé una matriz de variantes alrededor de OpenClaw:
OpenClawopenclawopen-clawOpenClawen el body del commitopenClawOpenclawOPENCLAWOpen Claw
El objetivo no era demostrar que el reporte original era falso. Era responder algo más acotado: si el claim general "Claude Code bloquea commits con OpenClaw" se sostiene como regla general en mi entorno actual.
Resultado
Los 8 commits pasaron.
No hubo bloqueo.
No hubo redirección visible de billing.
No hubo negativa de Claude Code al operar sobre el repo por la presencia de OpenClaw en el historial.
Eso contradice el ángulo original de mi post.
La conclusión honesta es esta:
No puedo afirmar que el reporte original fuera falso. Sí puedo afirmar que el claim general "Claude Code bloquea commits con OpenClaw" no se sostiene como regla general en Claude Code 2.1.126.
Y esa diferencia importa.
Un repro que no reproduce no invalida automáticamente el evento original. Puede haber diferencias de versión, flags server-side, cuenta, región, billing, plan, sesión, prompt exacto, historial del repo o timing. Pero sí invalida una generalización fuerte.
Mi post anterior generalizaba demasiado.
Qué sí sabemos
Sabemos que hubo un reporte viral.
Sabemos que el caso fuerte involucraba más que una palabra en un subject: hablaba de openclaw.inbound_meta.v1 en historial Git y comportamiento posterior de claude -p "hi".
Sabemos que mi repro público en Claude Code 2.1.126 no reprodujo el bloqueo.
Sabemos que los 8 casos de la matriz de commits pasaron.
Sabemos que, al menos en esa versión y en ese entorno, no alcanza con meter OpenClaw en commits para disparar el comportamiento reportado.
Eso es mucho menos explosivo que "Claude Code censura commits".
También es mucho más defendible.
Qué no sabemos
No sabemos si el reporte original ocurrió exactamente como fue contado.
No sabemos si Anthropic cambió algo después del thread.
No sabemos si había una flag server-side activa para algunas cuentas.
No sabemos si el comportamiento dependía de billing, plan, región, workspace, permisos, repo previo o algún estado que mi harness no replicó.
No sabemos si openclaw.inbound_meta.v1 era la causa real o solo una correlación en un caso más complejo.
Y no sabemos si Claude Code tiene otras capas de policy sobre acciones de agente que puedan fallar de forma silenciosa en otros escenarios.
Esa última parte sigue importando. Pero no se prueba con este caso.
La lección técnica
La lección no es "Anthropic censura commits".
Con el dato que tengo hoy, esa frase es demasiado fuerte.
La lección es más aburrida y más importante:
- los reportes virales sin versión exacta son frágiles;
- los agentes necesitan validación post-acción;
- un sistema con billing, policy y flags server-side puede cambiar de comportamiento sin que tu repro local lo explique;
- si vas a acusar a una herramienta de bloquear una acción, necesitás HEAD antes/después, logs, versión, comando exacto y estado observable.
Esto aplica a Claude Code, Cursor, Copilot CLI y cualquier agente que ejecuta herramientas reales.
Cuando un agente dice o parece haber hecho algo, hay que verificar el efecto. No alcanza con confiar en la narrativa del modelo ni en la intuición del operador.
Para commits, la validación mínima es aburrida:
before=$(git rev-parse HEAD)
# correr la acción del agente
after=$(git rev-parse HEAD)
if [ "$before" = "$after" ]; then
echo "No se creó un commit nuevo" >&2
exit 1
fiEsto no resuelve el misterio de OpenClaw. Pero evita que un flujo automatizado "crea" que algo pasó cuando no pasó.
Corrección pública
El post original tenía una tesis con más confianza que evidencia.
La versión corregida es esta:
Intenté reproducir el caso viral de OpenClaw en Claude Code. Armé un repo público, documenté la matriz y corrí los casos en Claude Code 2.1.126. Mi resultado contradice el claim general de que Claude Code bloquea commits con OpenClaw como regla.
No puedo demostrar que el reporte original sea falso.
Sí puedo decir que mi repro no lo confirma.
Y si la evidencia no sostiene el titular, el titular se cambia.
¿Buscás este enfoque para tu equipo?
Conocé mis casos técnicos o conversemos sobre un rol senior, arquitectura y liderazgo técnico.
Artículos Relacionados
Claude API key seguridad: por qué el .env no es opcional
Pegar una API key de Claude o DeepSeek directo en el código "para probar rápido" deja rastro en el historial de git y en los logs. Una guía prudente sobre variables de entorno, rotación y qué mirar antes de compartir un repo.
09 sept 2026 · 7′ · Tutoriales · nextjs · anthropic
setQueryData después de una Server Action: el patrón que cierra el gap
La Server Action se resuelve, el toast dice "guardado" y la UI todavía muestra el dato viejo por un instante. Ese instante es el gap que setQueryData cierra sin esperar el roundtrip completo del server.
08 sept 2026 · 7′ · Tutoriales · Next.js · React
fp-ts alternativas en TypeScript: cuándo vale la abstracción
Después de mostrar cómo un union type nativo reemplaza a Either y Option en la mayoría de los casos, toca la parte incómoda: decir dónde fp-ts sí gana. No es en todos lados, y esa es la postura.
08 sept 2026 · 7′ · Tutoriales · TypeScript · node.js
Comentarios (0)
¿Qué pensás de esto?
Dejá tu comentario en 10 segundos.
Usamos tu login solo para mostrar tu nombre y avatar. Nada de spam.
Todavía nadie comentó. Sé el primero — tu opinión vale oro cuando somos pocos.