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.
Artículos Relacionados
The Birth and Death of JavaScript (2014): qué sigue siendo verdad y qué ya no
Una charla de 2014 predijo que JavaScript moriría reemplazado por ASM.js. Una década después, JS sigue vivo pero la tensión que señaló es más real que nunca. Esto es lo que conviene extraer, lo que hay que ignorar y cómo convertirlo en una decisión técnica concreta.
Métodos formales y el futuro de la programación: qué vale la pena probar y dónde está el techo
Formal methods aparece cada tanto en el radar técnico como la solución que la industria ignoró. Mi lectura: el problema que señala es real, pero la receta que circula omite costos que cambian la ecuación.
Tokens de autenticación: JWT, Paseto y session tokens — el árbol de decisión que me faltaba
No existe el token perfecto, existe el token correcto para el modelo de amenaza de cada sistema. Árbol de decisión práctico con criterio técnico real para elegir entre JWT, Paseto v4 y session tokens opacos en TypeScript — sin dogma, sin benchmarks inventados.
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.