A transparent look at the local agent
Data, storage & privacy
What HubBound collects
HubBound collects only the signals made available by each connected provider. The table below summarizes the current integration boundary instead of implying that every provider sends the same data.
We do not intentionally collect or store prompt text through native telemetry. Personal information (PII) is treated as confidential and should be handled as sensitive data throughout the local and cloud flows.
| Claude Code | Native OTLP signals plus configured lifecycle hooks. We retain provider/session identifiers, operational attributes and hook event metadata needed for analytics. |
| Gemini CLI | Native OTLP telemetry plus configured lifecycle hooks and their operational event metadata. |
| Codex CLI | Native OTLP telemetry plus configured lifecycle hooks. Native prompt logging is disabled in the managed configuration. |
| GitHub Copilot | Native OTLP telemetry through the VS Code settings file. HubBound does not install a Copilot hook buffer. |
| Cursor | Lifecycle hook events configured in Cursor's hooks file; no native OTLP channel is configured by HubBound. |
| Antigravity | The supported lifecycle hook events from its Gemini-based hooks configuration. |
| HubBound runtime | Its own daemon resource samples and the Git identity fields required for device enrollment/reconciliation when a valid identity is available. |
- The providers do not all expose the same signals, schemas or event names; availability depends on the provider and its version.
- Native prompt logging is disabled for Claude Code and Codex where HubBound controls those settings.
- Hook payloads are provider-controlled event inputs. We do not make a stronger no-prompts guarantee for raw hook payloads without an additional redaction policy.
- Hook capture may also record the current working directory and Git status metadata when available.
What gets installed or changed
HubBound installs only the pieces required for the selected provider integration. The provider matrix below shows the boundary: settings, hooks and local routing, not a copy of your project files.
| Claude Code | Native OTLP settings, lifecycle hook entries and a HubBound hook capture script. |
| Gemini CLI | Native OTLP settings, lifecycle hook entries and a HubBound hook capture script. |
| Codex CLI | OTLP exporter settings, lifecycle hook commands and a HubBound hook capture script. |
| GitHub Copilot | The three native OTLP keys HubBound needs in the VS Code user settings file; no Copilot hook script. |
| Cursor / Antigravity | Lifecycle hook entries and a HubBound hook capture script; no native OTLP configuration from HubBound. |
| HubBound itself | The CLI, daemon, agent and helper, plus their local service, database, buffer and update paths described above. |
- The current installer does not install a kernel driver, browser extension or a general-purpose full-disk indexer.
- Optional artifacts and kits materialize only HubBound-owned files in supported tool directories and use ownership markers for cleanup.
- A hook is executable code in a provider's lifecycle. Install one only when you trust the artifact and understand its provider permissions.
What is sent to HubBound
Cloud traffic uses the configured HubBound API URL (https://api.hubbound.net by default). The normal analytics path does not send the human login token: the daemon uses the user-owned device credential and DPoP proof with analytics:write / analytics:check scopes.
| Device enrollment | Public device key, key thumbprint, hostname/device name, platform, app version, requested scopes and the Git identity read during login. The private key stays local; the human access token is used in memory for enrollment and is not persisted as the login credential. |
| Analytics upload | Gzipped JSONL rows from the six active local streams: sessions, metric points, events, spans, resource snapshots and hook rows. The payload is capped locally at 3 MB per upload and is sent to /analytics/put-metrics. |
| Analytics job check | The upload job ID and the resulting status are queried at /analytics/check-job. The response is stored as local upload/audit state. |
| Distribution sync | Authenticated requests fetch the distributions, artifact/kit metadata and bundles available to the account/team/org, then cache the resolved install state locally. A normal sync does not upload arbitrary project files. |
| Git identity reconciliation | When the device is enrolled and the email is valid, the daemon sends Git user.name, Git user.email and the HubBound app version at startup and once per day. |
| Signed updates | The agent checks the signed release manifest and downloads the selected platform artifact. Applying it is a separate elevated operation; updates are verified before the helper replaces the installed suite. |
- Analytics collection/export is enabled by default in the current build and there is no dedicated CLI or environment-variable opt-out for that pipeline. Stopping/uninstalling the daemon stops the local receiver and its scheduled work, but it is a broader operational change.
- Server-side retention, access controls and downstream processing are not fully defined by this client repository. Treat the client-side payload list above as the authoritative statement of what this binary can send.
What HubBound controls — and what it does not
The daemon has elevated privileges because it may need to write system-managed provider settings and run as an operating-system service. That is a meaningful trust boundary, so the affected paths are intentionally explicit.
| HubBound controls | Its own databases, queues, logs, buffers, credentials pointer, update files, release tree and marked artifact files; the listed provider settings keys/hooks; the local OTLP receivers; daemon/agent schedules; and its OS service lifecycle. |
| HubBound does not control | Unmarked provider files or arbitrary files in your projects. Profile switching and uninstall are designed to leave enforced/foreign/unmarked content alone. |
| Watching is not uploading | A watcher event normally enqueues doctor or ingestion. A changed settings file is not automatically copied to the cloud; analytics upload reads the normalized local database streams described above. |
| Remote retract is explicit | hubbound uninstall is local by default. Retracting the direct remote distribution requires --remote; a local uninstall does not silently delete the remote distribution. |
| Updates are guarded | The user agent downloads and verifies signed release metadata/artifacts. The privileged helper applies a staged, verified suite and can restart the daemon; applying is prompted unless explicitly confirmed. |
Local retention and cleanup
Local analytics rows are retained until they are successfully synchronized and pass the local TTL. The default is 60 days; unsynchronized rows are not eligible for that purge. This is a local cleanup policy, not a statement about how long the HubBound backend keeps uploaded data.
JSONL buffers are ingested incrementally with offsets and compacted after consumed data reaches roughly 1 MiB. The daemon warns when a buffer reaches 50 MiB; it does not silently treat the warning as proof that data was uploaded.
| After successful analytics sync | The upload payload file is removed, the successful row ranges advance their cursors, and later TTL runs may delete synced rows older than the configured period. |
| Failed/pending analytics sync | The local payload and row state are retained for retry or diagnosis. A failed upload does not advance the synced cursor. |
| Logout | Attempts remote device revocation, deletes the local user credential even if the network is unavailable, and clears the daemon's credential pointer. It does not erase the telemetry database. |
| Artifact uninstall | Removes local provider material, cache and install ledger entries for the selected artifact/kit, subject to ownership markers. It is not a full HubBound data wipe. |
How to inspect or reduce the footprint
Before removing anything, inspect the effective paths on the machine and distinguish user-owned credentials from the root daemon's data. The CLI provides status/diagnostic commands; filesystem cleanup should be deliberate because deleting a database also deletes unsynchronized evidence.
$ hubbound auth status
$ hubbound device status
$ hubbound doctor # diagnose; does not repair
$ hubbound analytics doctor # inspect upload backlog
$ hubbound daemon status
$ hubbound auth logout # revoke/delete device credential
$ hubbound daemon stop # stop collection and scheduled daemon work
- Use doctor/analytics doctor first: they expose configuration and backlog state without requiring you to open raw SQLite files.
- If you need a complete uninstall or data deletion policy, treat it as an operational procedure: stop services, revoke/logout, preserve evidence if needed, then remove the appropriate user and system roots. Do not assume artifact uninstall does this for you.
- If your organization manages provider settings, enforced files or device scopes, local cleanup may not remove the organization's remote distribution or policy.
Important boundaries
Provider behavior matters. Claude Code, Gemini CLI, Codex CLI, Cursor, GitHub Copilot and Antigravity do not emit the same signals, and their payload schemas can change independently of HubBound.
The safest mental model is: HubBound stores what its local integrations receive, keeps it in a local database first, and uploads the database rows only through the authenticated analytics pipeline. Raw hook payloads are the exception that deserves the most care because they preserve provider event input for local analytics.
- Do not paste raw metrics.db rows or hook JSONL into tickets without reviewing them for paths, identity, prompt/tool details and Git status.
- A local HTTP receiver is not the same as a cloud endpoint: the daemon receives provider telemetry locally before any analytics export occurs.
- This page should be updated whenever a provider, capture script, schema, upload stream, retention default or install target changes.