Claude Code remoto — visualizar outputs (Rich) desde el cel

Cuando Claude Code corre en un servidor remoto y el output usa Rich (tablas, paneles, colores), la terminal SSH del cel no lo renderiza como imagen. Solución: exportar el output a SVG/CSV y servirlo por un túnel temporal de Cloudflare.

Flujo

  1. Rich exporta su propio output con fidelidad (colores, formato) vía Console(record=True) + console.save_svg(). No hace falta ninguna herramienta externa de captura de pantalla.
  2. Se levanta un servidor HTTP simple sobre el directorio de salida:
    python -m http.server 8000
  3. Se abre un túnel de Cloudflare efímero (sin cuenta, sin config previa) apuntando a ese puerto:
    cloudflared tunnel --url http://localhost:8000
  4. cloudflared imprime una URL pública tipo https://random-words-1234.trycloudflare.com. Se abre esa URL en el navegador del cel (o cualquier dispositivo) y se ve el SVG tal cual se vería en la terminal.

Prompt de ejemplo para Claude Code

Genera una tabla de ejemplo con rich (5-6 filas, datos random tipo ventas),
expórtala con console.save_svg() a output.svg, y también guarda los mismos
datos en output.csv. Ponlos en una carpeta ./output. Levanta
`python -m http.server 8000` en esa carpeta y después
`cloudflared tunnel --url http://localhost:8000`. Dame la URL pública que
imprima el tunnel.

Túnel efímero vs. túnel con nombre del host

Si el host ya tiene un túnel con nombre corriendo (ver Túneles de Cloudflare), cloudflared tunnel --url ... sin más igual intenta usar el config.yml del sistema en /etc/cloudflared/ por default, aunque el objetivo sea un túnel rápido sin cuenta — hereda las reglas de ingress de ese config y termina devolviendo 404 porque el hostname aleatorio de trycloudflare.com no matchea ninguna regla. La forma correcta de aislar el túnel efímero de esa config preexistente es forzar uno vacío explícito:

cloudflared tunnel --config /dev/null --url http://localhost:8000

Confirmado de nuevo el 2026-09-07 (ctunlinux), con evidencia adicional: corriendo el quick tunnel con --loglevel debug, la petición fallida sí aparece en el log — ingressRule=9 originService=http_status:404 — es decir, cloudflared sí recibe la petición y la enruta con las reglas de ingress del config.yml del túnel nombrado; solo cae en su catch-all porque el hostname aleatorio no matchea nada ahí. El 404 resultante trae headers reales de Cloudflare (server: cloudflare, cf-ray válido), lo cual engaña y parece un bloqueo de red — se descartó explícitamente probando que iptables/nft no tienen reglas de bloqueo y que el handshake TLS/QUIC contra trycloudflare.com se completa sin problema. Detalle completo con la tabla de hostnames de ese host en ctunlinux.

Notas

  • La URL del túnel es pública mientras el proceso esté vivo — cualquiera con el link puede entrar. Cortar el túnel apenas se termina de ver el output, sobre todo si hay datos sensibles (credenciales, IPs internas).
  • Alternativa sin exponer nada a internet: usar NetBird si ya está conectado en el cel — se sirve el directorio igual con http.server y se entra por la IP interna de NetBird, sin túnel público.
  • Rich no exporta PNG nativo; el SVG se renderiza bien en navegadores móviles sin conversión adicional.

Véase también

  • Túneles de Cloudflare — túneles persistentes vs. este uso efímero, y por qué un config de sistema preexistente puede interferir con uno nuevo
  • NetBird — alternativa privada al túnel público
  • claude-skills — repo de skills propios de Claude Code — skill hermano (torep) para exploraciones que arman reporte HTML acumulado en vez de SVG suelto, pero que a propósito no usa túnel público — solo red local/NetBird, decisión distinta a esta página