Stop inherited T3 telemetry and establish privacy-safe ZL product analytics

[lrequena]

Context

The server already contains a custom PostHog batch client. The current implementation is inherited from upstream T3 Code and is unsafe for ZL distribution as-is:

• telemetry is enabled by default;
• the upstream PostHog project key and US ingestion host are hard-coded defaults;
• the running zl-code-server.service has no telemetry/PostHog override variables, so it inherits those defaults;
• startup and provider lifecycle events are emitted;
• the distinct ID prefers a SHA-256 hash of the local Codex account ID, then the Claude user ID, before falling back to a random installation ID;
• event properties still include t3CodeVersion.

The PostHog project token is intentionally not repeated in this issue. It is visible in the imported source and matches upstream.

This product analytics path is separate from:

1. local provider usage and API-equivalent cost analytics;
2. local NDJSON operational telemetry;
3. opt-in remote OTLP traces and metrics;
4. future ZL Cloud billing records.

Immediate containment

• Disable outbound product telemetry by default.
• Remove the inherited PostHog project key default.
• Require an explicit ZL-owned destination and project token before egress is possible.
• Add tests proving there is no HTTP request when disabled or unconfigured.
• Stop deriving analytics identity from Codex or Claude account files.
• Document the behavior and configuration.
• Audit releases and local service configuration for any other T3-owned outbound destination.

ZL product analytics design

• Use an explicit, versioned event allowlist; do not expose a generic arbitrary-property capture surface to product code.
• Use a resettable random installation identifier for unauthenticated local usage.
• Use ZL account/tenant identifiers only for authenticated ZL Cloud activity under the applicable disclosure and agreement.
• Never collect prompts, source code, diffs, filenames, repository names, filesystem paths, thread titles, terminal output, command/tool arguments, provider credentials, or raw model responses.
• Keep browser autocapture disabled initially.
• Keep session replay disabled for the coding workspace; revisit only with explicit consent and a demonstrated deny-by-default redaction model.
• Provide a visible telemetry setting/status and identity reset.
• Define retention, deletion, regional hosting, access control, and incident-response policy before enabling collection.
• Separate official hosted/distributed-build policy from source-build and self-hosted defaults.
• Add event-schema review and automated sensitive-property tests.

Initial questions to answer

• PostHog Cloud EU, PostHog Cloud US, self-hosted PostHog, or another tool?
• Which activation and retention decisions will each event support?
• What consent model applies to official ZL distributions versus self-hosted instances?
• Which aggregate operational metrics belong in OTLP rather than product analytics?

Candidate first-party events

Start small and server-side: application started, first provider detected, first thread completed, ZL Cloud environment linked, second device connected, remote approval completed, invitation sent/accepted, trial started, and subscription started. Properties should be limited to coarse platform/build/provider kind, outcome, duration buckets, and feature/version identifiers.

Related: #114, #115, and PR #116.

[lrequena]

Opened in the wrong repository by automation; closing immediately.