Privacy & trust overview
Your Code.
Your Machine.
Your Control.
A technical, plain-language account of how SuperX Code handles information. It is written for developers and kept consistent with the actual architecture — not a generic privacy template.
What the website collects
This marketing site is a static Astro build. It loads no third-party analytics, advertising, or session-replay scripts.
- There is no tracking pixel, advertising SDK, or analytics script on these pages.
- The feedback page uses Google Firebase Authentication and Firestore. It stores the display name, star rating, message text, and authenticated account identifier you submit, plus timestamps and publication status.
- An email address is only published as a display name when you explicitly opt in and it matches your authenticated account email.
- The hosting provider may keep standard request logs needed to serve the site. SuperX Code adds no analytics of its own on top of that.
What stays on your machine
SuperX Code is a terminal-first application that runs against a project directory you choose.
- Project source files remain in the directory you open. They are not uploaded to SuperX Code servers.
- Session history, messages, and related metadata are stored in a local SQLite database under your OS data directory.
- Model credentials you configure — API keys and OAuth tokens — are stored in that same local application database.
- You can point the application at a different data directory or database path through configuration.
What is sent to AI providers
Model requests go to the provider or endpoint you configure. SuperX Code does not proxy model traffic through its own servers.
- A model request carries the prompt, the selected code context, tool results, and the history needed for that step.
- That request is sent to your chosen provider using your own credential, under that provider's privacy and data-processing terms.
- Retention and training behavior depend on the provider, your account plan, and its configuration — not on SuperX Code.
- A local or self-hosted OpenAI-compatible endpoint keeps model requests on infrastructure you control when configured correctly.
How API keys are handled
Credentials are local application data, not a SuperX Code cloud secret.
- Provider API keys and OAuth credentials are stored in the local application database.
- They are used to authenticate requests directly to the provider you select.
- They are not transmitted to SuperX Code services as part of normal operation.
- The database file is protected by your operating-system account and file permissions. Anyone with access to your machine or that file could read the credentials, so keep disk access and backups protected.
Session and memory storage
Conversation state is durable and local so work survives restarts.
- Sessions, messages, and queued input are persisted in the local database.
- Conversation history included in a model request is sent to your provider to produce a response.
- Deleting a session removes it from the local database according to the application's deletion behavior.
- Backups you create of the data directory include the same session and credential data.
Telemetry and logging
This website ships no tracking scripts, and application-level export is opt-in.
- This website ships no analytics or tracking scripts.
- The application supports opt-in OpenTelemetry (OTLP) export configured through standard OTEL environment variables; when unset, no OTLP export endpoint is used.
- Local application and server logs can contain operational detail. Review your log configuration before sharing logs publicly.
- Optional account and update services, when enabled, contact SuperX services to provide those functions. This page covers the local application and this website, not the internal design of those services.
Retention and deletion
Local data is under your control; service data follows service behavior.
- Local sessions and credentials persist until you delete them or remove the local database.
- You can delete feedback you submitted from the feedback page; the author may remove their own review.
- Account and operational records held by optional SuperX services follow the applicable service terms.
- Because model requests are handled by your provider, their retention is governed by that provider's policy.
Third-party services
Only the services needed for a function are involved.
- Google Firebase provides authentication and the feedback datastore on this website.
- Your selected AI provider processes model requests.
- Your hosting and download infrastructure serves this site and installers.
- This website has no advertising, analytics, or session-replay integrations.
Privacy and security controls
Controls that exist in the product today.
- Tool permissions can allow, ask, or deny actions by policy.
- You choose the model provider and can configure a compatible or local endpoint.
- You decide which project directory the agent can operate in.
- Server binding and access can be limited to your machine or trusted hosts depending on how you run it.
Known limitations
Honest boundaries of the current implementation.
- Cloud model providers receive the context included in a request. SuperX Code cannot control their retention or training behavior.
- Stored credentials are protected by OS and file permissions, not by an additional application-level encryption layer described here.
- An optional account and update service exists, so this is not a zero-network product.
- This page is a technical overview, not a legal contract. The legal privacy policy is maintained separately.
The one boundary to remember
SuperX Code and your AI provider are separate systems with separate policies.
Optional account and update services are a separate path and do not carry your source code.
This page explains the technical design. For legal terms, see theprivacy policy. Where the two differ, applicable law and the legal policy govern.
Build Anything.
Secure What You Build.
Powerful AI coding, integrated security, and a privacy-first architecture.