Telemetry and privacy

    Extension.js collects minimal, anonymous telemetry from CLI and build workflows so the framework can improve without turning projects into tracking surfaces.

    The privacy bar is strict by design:

    • Telemetry is coarse, aggregate-friendly, and product-focused
    • Source code and project contents are never collected
    • Extension.js telemetry should stay below the invasiveness users typically accept from web framework telemetry such as Next.js/Vercel usage data
    • Users can disable telemetry for any command with --no-telemetry

    What Extension.js collects

    Extension.js CLI/build telemetry is limited to high-level workflow data such as:

    • command lifecycle (cli_boot, cli_command_start, cli_command_finish)
    • browser target counts and multi-browser usage
    • privacy-safe manifest counts and manifest surface buckets
    • coarse project-shape signals like package manager, framework family, TypeScript usage, monorepo usage, and broad ecosystem booleans such as has_next_dependency
    • build output summaries like asset counts, bytes, warnings/errors, and zip intent

    These signals help answer product questions such as:

    • Are users only experimenting locally, or are they repeatedly producing release artifacts?
    • How common are multi-browser release flows?
    • Are CI-style and machine-readable workflows becoming common?

    Workflow cohorts for dashboards

    Extension.js also emits a normalized workflow_profile event to make aggregate reporting easier in tools such as PostHog.

    Each run is assigned one cohort:

    • local_only for local iteration without strong release or automation signals
    • shipping for release-oriented behavior such as production commands, zip artifacts, or multi-browser builds
    • automation_heavy for machine-oriented behavior such as --wait, --no-browser, or machine-readable output

    The event includes only coarse fields such as:

    • workflow_cohort
    • has_shipping_intent
    • has_automation_intent
    • shipping_signal_count
    • automation_signal_count
    • primary_workflow_signal
    • package_manager
    • framework_primary
    • has_next_dependency
    • has_turbo_dependency

    What Extension.js never collects

    The CLI/build telemetry contract explicitly excludes:

    • source code, manifest contents, HTML output, or package.json contents
    • repo names, Git remotes, GitHub org/user names, branch names, commit SHAs, or preview URLs
    • raw dependency lists or raw permission lists
    • file paths, local URLs, environment variable values, or any personal data
    • IP addresses in telemetry payloads

    Public telemetry vs product analytics

    For Extension.js itself, telemetry is the public, privacy-safe layer described in repository TELEMETRY.md.

    That contract is intentionally narrower than product-side operational analytics you might use in hosted products. If a field could identify a specific repository, user, or company, it does not belong in Extension.js CLI telemetry.

    Opt out

    Use --no-telemetry on any command:

    extension build --browser=chrome,firefox --no-telemetry

    Best practices

    • Keep telemetry fields coarse: booleans, enums, and buckets beat freeform strings.
    • Separate framework telemetry from hosted-product analytics contracts.
    • Document every field publicly before expanding collection.
    • Treat privacy regressions as product regressions.

    Next steps

    • Review Global flags for --no-telemetry.
    • Use Build and Dev for release and automation workflows.
    • Read the repository-level TELEMETRY.md contract for the exact event list.