Una mirada transparente al agente local
Datos, almacenamiento y privacidad
Qué recolecta HubBound
HubBound recolecta únicamente las señales que cada provider conectada pone a disposición. La tabla resume el límite actual de cada integración, sin asumir que todas las providers envían los mismos datos.
No recolectamos ni almacenamos intencionalmente texto de prompts mediante la telemetría nativa. La información personal (PII) se trata como confidencial y debe manejarse como información sensible en los flujos locales y cloud.
| Claude Code | Señales OTLP nativas más hooks de lifecycle configurados. Conservamos identificadores de provider/session, atributos operativos y metadata de eventos necesaria para analytics. |
| Gemini CLI | Telemetría OTLP nativa más hooks de lifecycle configurados y su metadata operativa de eventos. |
| Codex CLI | Telemetría OTLP nativa más hooks de lifecycle configurados. El logging nativo de prompts queda desactivado en la configuración administrada. |
| GitHub Copilot | Telemetría OTLP nativa a través del settings de VS Code. HubBound no instala un buffer de hooks para Copilot. |
| Cursor | Eventos de lifecycle de hooks configurados en el archivo de hooks de Cursor; HubBound no configura un canal OTLP nativo. |
| Antigravity | Los eventos de lifecycle soportados por su configuración de hooks basada en Gemini. |
| Runtime de HubBound | Snapshots del propio daemon y los campos de identidad Git necesarios para enrollment/reconciliación del device cuando existe una identidad válida. |
- Las providers no exponen las mismas señales, schemas ni nombres de eventos; la disponibilidad depende de la provider y su versión.
- El logging nativo de prompts está desactivado para Claude Code y Codex cuando HubBound controla esos settings.
- Los payloads de hooks son entradas de eventos controladas por cada provider. No afirmamos una garantía más fuerte de cero prompts en payloads crudos sin una política adicional de redacción.
- El capture de hooks también puede registrar el directorio actual y metadata de estado de Git cuando está disponible.
Qué instalamos o cambiamos
HubBound instala únicamente las piezas necesarias para la integración seleccionada de cada provider. La matriz muestra el límite: settings, hooks y routing local, no una copia de los archivos de tus proyectos.
| Claude Code | Settings OTLP nativos, entradas de hooks de lifecycle y un script de captura de hooks de HubBound. |
| Gemini CLI | Settings OTLP nativos, entradas de hooks de lifecycle y un script de captura de hooks de HubBound. |
| Codex CLI | Settings de exporters OTLP, comandos de hooks de lifecycle y un script de captura de hooks de HubBound. |
| GitHub Copilot | Las tres keys OTLP nativas que HubBound necesita en el settings de usuario de VS Code; no instala un script de hooks de Copilot. |
| Cursor / Antigravity | Entradas de hooks de lifecycle y un script de captura de hooks de HubBound; no configura OTLP nativo desde HubBound. |
| El propio HubBound | El CLI, daemon, agent y helper, junto con sus paths locales de servicio, bases, buffers y updates descritos arriba. |
- El installer actual no instala un kernel driver, una extensión de navegador ni un indexador general de todo el disco.
- Los artifacts y kits opcionales solo materializan archivos propiedad de HubBound en directorios soportados de las tools y usan ownership markers para cleanup.
- Un hook es código ejecutable dentro del lifecycle de una provider. Instalá uno solo si confiás en el artifact y entendés sus permisos dentro de la tool.
Qué se envía a HubBound
El tráfico de nube usa la URL de API configurada (https://api.hubbound.net por defecto). El camino normal de analytics no envía el token humano del login: el daemon usa la credencial de device propiedad del usuario y una prueba DPoP con los scopes analytics:write / analytics:check.
| Enrollment del device | Public device key, thumbprint de la key, hostname/nombre del device, plataforma, versión de la app, scopes solicitados y la identidad Git leída durante login. La private key queda local; el token humano se usa en memoria para el enrollment y no se persiste como credencial de login. |
| Upload de analytics | Filas JSONL gzip de los seis streams locales activos: sesiones, puntos de métricas, eventos, spans, snapshots de recursos y filas de hooks. El payload tiene un límite local de 3 MB por upload y se envía a /analytics/put-metrics. |
| Check del job de analytics | El job ID del upload y su status resultante se consultan en /analytics/check-job. La respuesta queda como estado local de upload/auditoría. |
| Sync de distribuciones | Requests autenticados traen las distribuciones, metadata y bundles de artifacts/kits disponibles para la cuenta/team/org, y guardan localmente el install resuelto. Un sync normal no sube archivos arbitrarios de tus proyectos. |
| Reconciliación de identidad Git | Cuando el device está enrolled y el email es válido, el daemon envía Git user.name, Git user.email y la versión de HubBound al iniciar y una vez al día. |
| Updates firmados | El agent consulta el manifiesto de release firmado y descarga el artifact de la plataforma. Aplicarlo es una operación elevada separada; el helper verifica antes de reemplazar la suite instalada. |
- La recolección/export de analytics está activa por defecto en el build actual y no existe un opt-out dedicado por CLI o variable de entorno para ese pipeline. Parar/desinstalar el daemon detiene el receiver local y sus jobs, pero es un cambio operativo más amplio.
- La retención del lado servidor, sus controles de acceso y el procesamiento downstream no están definidos completamente en este repositorio cliente. La lista de payloads anterior es la declaración autoritativa de lo que este binary puede enviar.
Qué controla HubBound — y qué no
El daemon tiene privilegios elevados porque puede necesitar escribir settings de providers administrados por sistema y correr como servicio del sistema. Es un trust boundary importante; por eso los paths afectados son explícitos.
| HubBound controla | Sus bases, queues, logs, buffers, pointer de credencial, archivos de update, árbol de releases y archivos de artifacts marcados; las keys/hooks de settings de providers listados; receivers OTLP locales; schedules del daemon/agent y lifecycle del servicio del sistema. |
| HubBound no controla | Archivos de providers sin marca ni archivos arbitrarios de tus proyectos. El switch de perfiles y uninstall están diseñados para dejar intacto contenido enforced, ajeno o sin ownership marker. |
| Vigilar no es subir | Un evento de watcher normalmente encola doctor o ingesta. Que cambie un settings no significa que el archivo completo se copie a la nube; el upload lee los streams normalizados de la base local descritos arriba. |
| Retract remoto explícito | hubbound uninstall es local por defecto. Para retirar la distribución remota directa hay que pasar --remote; uninstall local no borra silenciosamente la distribución remota. |
| Updates protegidos | El agent descarga y verifica metadata/artifacts de release firmados. El helper privilegiado aplica una suite staged y verificada y puede reiniciar el daemon; aplicar pide confirmación salvo que se confirme explícitamente. |
Retención y limpieza local
Las filas locales de analytics se conservan hasta que se sincronizan exitosamente y pasan el TTL local. El default es 60 días; las filas no sincronizadas no son elegibles para ese purge. Es una política de limpieza local, no una declaración sobre cuánto conserva el backend de HubBound.
Los buffers JSONL se ingieren incrementalmente con offsets y se compactan cuando los datos consumidos llegan aproximadamente a 1 MiB. El daemon avisa cuando un buffer llega a 50 MiB; el warning no prueba que los datos hayan sido subidos.
| Después de sync exitoso | Se elimina el archivo de payload, avanzan los cursors de rangos exitosos y los TTL posteriores pueden borrar filas synced más antiguas que el período configurado. |
| Sync fallido/pendiente | El payload local y el estado de filas se conservan para retry o diagnóstico. Un upload fallido no avanza el cursor synced. |
| Logout | Intenta revocar el device remotamente, borra la credencial local del usuario aunque no haya red y limpia el pointer de credencial del daemon. No borra la base de telemetría. |
| Uninstall de artifact | Elimina material local de providers, cache y entradas del ledger del artifact/kit seleccionado, sujeto a ownership markers. No es un borrado completo de datos de HubBound. |
Cómo inspeccionar o reducir la huella
Antes de borrar algo, inspeccioná los paths efectivos en el equipo y distinguí las credenciales del usuario de los datos del daemon root. El CLI ofrece comandos de status/diagnóstico; la limpieza del filesystem debe ser deliberada porque borrar una base también borra evidencia aún no sincronizada.
$ hubbound auth status
$ hubbound device status
$ hubbound doctor # diagnostica; no repara
$ hubbound analytics doctor # inspecciona backlog de uploads
$ hubbound daemon status
$ hubbound auth logout # revoca/borra credencial de device
$ hubbound daemon stop # detiene collection y jobs del daemon
- Usá doctor/analytics doctor primero: muestran configuración y backlog sin obligarte a abrir SQLite crudo.
- Si necesitás un uninstall completo o un procedimiento de borrado de datos, tratálo como operación: pará servicios, hacé logout/revoke, preservá evidencia si hace falta y luego borrá los roots de usuario y sistema apropiados. No asumás que artifact uninstall hace esto.
- Si tu organización administra settings, archivos enforced o scopes del device, la limpieza local puede no retirar la distribución remota ni la policy de la organización.
Límites importantes
El comportamiento de cada provider importa. Claude Code, Gemini CLI, Codex CLI, Cursor, GitHub Copilot y Antigravity no emiten las mismas señales, y sus schemas pueden cambiar de forma independiente de HubBound.
El modelo mental más seguro es: HubBound guarda lo que reciben sus integraciones locales, primero lo conserva en una base local y solo sube filas de esa base por el pipeline autenticado de analytics. Los payloads crudos de hooks merecen más cuidado porque preservan la entrada del evento de la provider para analytics local.
- No pegues filas crudas de metrics.db ni JSONL de hooks en tickets sin revisarlas por paths, identidad, detalles de prompts/tools y git status.
- Un receiver HTTP local no es lo mismo que un endpoint cloud: el daemon recibe la telemetría de las providers localmente antes de cualquier export de analytics.
- Esta página debe actualizarse cuando cambie una provider, un script de captura, el schema, los streams de upload, el TTL o un target de instalación.