Security fixes target the latest published release and the current main branch. Older builds may not receive fixes.

Do not open a public issue for a vulnerability or suspected credential leak. Use GitHub's private vulnerability reporting flow on the repository's Security tab when it is available. Otherwise, contact the repository owner through GitHub first and wait for a private channel before sharing technical details. If no private contact method is available, open an issue that asks the maintainer to enable private reporting without including vulnerability details.

Include the affected version or commit, Windows version, impact, and the smallest safe reproduction you can provide. Sanitized logs and a proposed fix are useful, but there is no guaranteed response-time SLA.

Appropriate reports include:

• credentials, provider responses, or sensitive account data crossing the renderer IPC boundary or being written to logs;
• unsafe credential-file updates, locking failures, or permission issues;
• command, argument, or path injection through configuration;
• a CSP bypass or another issue that exposes local data; and
• a dependency vulnerability that is reachable in this application.

Provider outages, quota discrepancies, and undocumented endpoint changes are usually regular bug reports unless they create a security impact.

The dashboard reads the Grok access token and only checks whether a non-empty refresh token exists. It never extracts that value into app state, sends it, logs it, passes it to the child process, calls the OAuth refresh endpoint, or writes auth.json itself. For a recognized expired session, it may run the official grok --no-auto-update models command with discarded output and a bounded timeout. The official CLI remains solely responsible for renewing and writing its credentials.

Renewal only accepts the official <home>/.grok/auth.json layout, is serialized across dashboard processes, and uses a per-source retry backoff.

If the local agy access token is expired, the dashboard may POST to Google's token endpoint. Google OAuth client IDs and secrets are not embedded in this repository. The client is resolved in this order:

1. ANTIGRAVITY_OAUTH_CLIENT_ID and ANTIGRAVITY_OAUTH_CLIENT_SECRET;
2. client_id / client_secret on the local login JSON;
3. a scan of an installed agy binary or Antigravity.app (same approach as CodexBar).

Resolved clients are never sent to the renderer and never logged. The dashboard does not write the OAuth file or OS keyring item. If no client is found, refresh is skipped and the panel reports SESSION EXPIRED until agy renews the login.

Never attach or paste any of the following:

• Claude credential files, access tokens, refresh tokens, or raw OAuth responses;
• Codex auth.json, authorization headers, cookies, or account identifiers;
• Grok Build auth.json, access or refresh tokens, or account/team identifiers;
• Cursor CLI auth.json, macOS Keychain / Linux secret-tool items, desktop state.vscdb tokens, session cookies, or account identifiers;
• Antigravity / agy OAuth access or refresh tokens, OS keyring items, or Google account identifiers;
• DeepSeek API keys;
• a dashboard config.json containing deepSeekApiKey;
• signing keys or certificate passwords; or
• unredacted screenshots, paths, or cache files that reveal usernames, plan details, balances, or other account information.

Use the built-in mock modes and clearly fake tokens for reproductions. Redact secrets rather than partially masking them. If a real credential was exposed, revoke or rotate it with the provider immediately and do not wait for a project response.

The application cache contains sanitized usage and balance data rather than provider credentials, but it can still contain private account information. Treat it as sensitive when preparing a report.