[Feature]: safely import Cockpit Tools Google Antigravity accounts

[agentHits]

Area

Authentication and account pool

Goal

Allow users to import existing Google Antigravity accounts exported by Cockpit Tools instead of repeating interactive browser OAuth for every account.

Imported refresh tokens are credentials and must remain inside OpenCodex's normal credential-storage boundary.

This issue tracks the Cockpit Tools → Google Antigravity import contract only.

Current status

Implementation is in progress in:

#1357
feat(auth): import Cockpit Tools accounts through safe adapters

The earlier #1077 approach was superseded.

The current implementation direction deliberately avoids accepting credentials through command-line arguments or ordinary configuration.

This issue should remain open until the accepted implementation lands on dev.

Supported v1 input

The supported v1 format is a Cockpit Tools Google Antigravity export containing one or more records conceptually shaped like:

[
  {
    "email": "user@example.com",
    "refresh_token": "<redacted>"
  }
]

Examples, screenshots, logs, tests, and issue comments must use placeholders only.

No real refresh token belongs in repository content or normal diagnostic output.

Supported surfaces

Dashboard

Provide the import action under:

Providers
  → Google Antigravity
    → Accounts
      → Import Accounts

The Dashboard should use a local file picker.

It must not:

• redisplay the file contents;
• redisplay refresh tokens;
• place credentials into persistent frontend state;
• return credentials after processing.

Only safe result information should be shown.

CLI

CLI import must accept credential material through:

ocx account import google-antigravity --format cockpit-tools --file <path>

or:

cat accounts.json | ocx account import google-antigravity --format cockpit-tools --stdin

Credential JSON must not be accepted as a positional/argv value.

Command arguments can be retained in:

• shell history;
• process listings;
• diagnostics;
• terminal transcripts.

File/stdin-only admission avoids that unnecessary exposure.

Import validation

For each record:

1. parse the supported Cockpit Tools format;
2. require the fields needed by the format;
3. reject malformed or unsupported entries;
4. use the refresh token to perform the provider validation required by the Antigravity account path;
5. derive authoritative account identity from the provider rather than trusting arbitrary caller-supplied identity;
6. verify any claimed email against the provider-derived identity where applicable;
7. resolve/validate the required Cloud Code Assist project;
8. only then persist the account through the normal Antigravity credential store.

An imported credential must not be marked healthy merely because the JSON parsed.

Duplicate handling

Imports must be deterministic.

If the provider-derived account identity already exists, the import should safely update/upsert that identity rather than creating duplicate pool entries.

Duplicate detection must be based on authoritative account identity rather than trusting only the email text supplied by the export.

Batch behavior

A Cockpit Tools export may contain multiple accounts.

The import result may report bounded aggregate/status information such as:

imported
updated
failed
unsupported

or equivalent fixed result codes.

Do not include:

• refresh tokens;
• access tokens;
• account IDs that are not already safe public identifiers;
• raw provider errors;
• raw import records.

Malformed successful responses from internal import components must fail closed rather than accidentally projecting unexpected data.

Credential handling

Imported refresh tokens must use the same protected credential-storage path as interactively authenticated Google Antigravity accounts.

The implementation must not place refresh tokens in:

• ordinary config.json provider configuration;
• request/history logs;
• usage records;
• telemetry;
• diagnostics;
• management API responses;
• Dashboard result objects;
• screenshots;
• error messages.

Raw import payloads should not be retained after processing.

Security boundaries

The import adapter must be explicitly allowlisted.

For v1:

provider = google-antigravity
format   = cockpit-tools

must be the proven contract.

Do not interpret this feature as generic arbitrary OAuth credential import.

Other Cockpit Tools provider formats should remain unsupported until their credential and validation contracts are separately established.

The import parser should also be bounded so an untrusted local export cannot cause unbounded parsing or processing.

Failure behavior

One bad record should not expose or corrupt other credentials.

Failures should use safe, bounded result codes and counts.

A failure to:

• refresh;
• derive identity;
• validate claimed identity;
• resolve the Cloud Code Assist project;
• persist the account;

must leave that record unavailable for routing.

Normal account import failure must not damage existing healthy Antigravity accounts.

After successful import

Successfully imported accounts should immediately become ordinary Google Antigravity accounts available to the existing account-management and pool machinery.

Import itself does not define:

• pool selection policy;
• automatic failover;
• quota aggregation;
• quota/reset presentation.

Those remain separate concerns.

Related issues

#1062

Broader Google Antigravity account-pool and management UX.

#1082

Per-account Gem/Cla quota display.

#695

Generic OAuth account-pool selection/failover architecture.

#1077

Superseded earlier implementation attempt.

#1357

Current implementation PR for this issue.

Acceptance criteria

• Cockpit Tools Google Antigravity exports can be imported from the Dashboard using a local file.
• CLI accepts imports through file or stdin only.
• Credential payloads cannot be supplied through argv.
• Multiple accounts can be processed in one import.
• Refresh tokens are never returned by management APIs.
• Refresh tokens are never written to normal logs, diagnostics, usage records, or configuration.
• Provider-derived identity is validated before persistence.
• Claimed identity is checked where applicable.
• Required Cloud Code Assist project state is validated.
• Existing account identities are updated/upserted deterministically rather than duplicated.
• Result projection contains only bounded safe status/count information.
• Malformed internal responses fail closed.
• Imported accounts become available through the normal Antigravity account-management path.
• Secret-shaped canary tests verify that credentials do not leak.
• Dashboard regression coverage exists.
• CLI/API regression coverage exists.
• Explicit maintainer security review is complete.
• Accepted implementation is merged into dev.

Checks

• Earlier unsafe argv-oriented design has been rejected.
• Current implementation direction is file/stdin based.
• Current implementation is scoped specifically to Cockpit Tools Google Antigravity exports.
• Main issue description contains no real credential.
• feat(auth): import Cockpit Tools accounts through safe adapters #1357 merged.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[agentHits]

Hi @lidge-jun!

Could you please consider implementing support for importing accounts exported from Cockpit Tools?

Many users manage multiple Google Antigravity / Gemini accounts using Cockpit Tools and export their account credentials in a standard JSON format containing email and refresh_token:

[
  {
    email: dhtri123@gmail.com,
    refresh_token: 1//0bb0d9rRw45k4CgYIARAAGA4SNwF-L9Irx1-c2zvfb8Yl2J4zuFnLoEd9f6gorHhbsw1V5F0I3jBGHGkfaQaAZnXHNjDwD_qAHsk
  }
]

Adding support for parsing and batch-importing this JSON array under Providers -> Google Antigravity -> Accounts (or via API/config) would allow users to quickly import their account pool into OpenCodex without having to manually perform interactive web OAuth for dozens of accounts one by one.

Thank you!

[lidge-jun]

Keeping this open — Cockpit Tools import is the piece of this campaign we most want to take. PR #1077 was closed with specific feedback: accept refresh tokens via file path or stdin only (argv leaks into shell history and process listings), include the required GUI screenshot evidence, and expect a maintainer-sponsored security review on the credential-import surface. A reopened PR addressing those three lands on a fast review track.

[agentHits]

Keeping this open — Cockpit Tools import is the piece of this campaign we most want to take. PR #1077 was closed with specific feedback: accept refresh tokens via file path or stdin only (argv leaks into shell history and process listings), include the required GUI screenshot evidence, and expect a maintainer-sponsored security review on the credential-import surface. A reopened PR addressing those three lands on a fast review track.

I probably won't be able to write a PR correctly. I'd be grateful if you or other participants could take care of this. Let me be the one pitching the ideas, and you, as a professional, implement them.

[Wibias]

Goal

Support importing Google Antigravity / Gemini accounts exported from Cockpit Tools so users can add existing accounts to OpenCodex without repeating interactive browser OAuth for every account.

The import flow must treat refresh tokens as credentials and avoid exposing them in logs, errors, diagnostics, screenshots, or persisted plaintext outside the existing credential-storage boundary.

Supported input

Add an import option under the Google Antigravity account-management surface that accepts Cockpit Tools-style JSON such as:

[
  {
    "email": "user@example.com",
    "refresh_token": "1//..."
  }
]

The UI should support both a single account and arrays containing multiple accounts.

Examples and tests must use placeholders only. No real refresh token should ever be committed to the repository or posted in issue/test fixtures.

Required behavior

Parse and validate

For each imported entry:

• require a syntactically valid email/account identifier where the provider requires it;
• require a non-empty refresh token;
• reject malformed records with a clear per-record error;
• do not echo the full refresh token in validation errors.

Credential handling

Imported refresh tokens must enter the same protected credential-storage path used by interactively authenticated Antigravity accounts.

The implementation must not:

• store refresh tokens in ordinary provider configuration;
• include them in logs;
• include them in usage/debug records;
• return them from management APIs after import;
• expose them in frontend state longer than required to submit the import;
• write them to telemetry or diagnostics.

Batch import

Support importing multiple accounts in one operation.

The result should identify which records:

• imported successfully;
• were duplicates;
• were invalid;
• failed provider validation.

A failure in one record should not unnecessarily discard valid independent records, unless the implementation deliberately uses an atomic mode and communicates that behavior clearly.

Duplicate handling

Do not silently create duplicate account entries.

If an imported account already exists, either:

• update/re-authorize the existing account safely; or
• skip it and report it as already present.

The chosen behavior should be deterministic and documented.

Account validation

Where practical, validate the imported credential with the provider before marking the account ready.

A credential that cannot currently be validated should not be presented as a confirmed healthy account.

UI

Suggested flow:

Providers
  -> Google Antigravity
    -> Accounts
      -> Import Accounts

The import dialog may provide:

• paste JSON;
• local file selection if supported safely;
• validation preview showing account identifiers only;
• import result summary.

The UI must never redisplay full refresh tokens after parsing.

Security requirements

Refresh tokens are secrets.

• Redact them from logs and errors.
• Do not serialize them into issue/debug output.
• Do not include them in analytics.
• Do not preserve raw import payloads after processing.
• Ensure management API responses do not return stored refresh tokens.
• Add regression tests for secret redaction.

Any refresh token previously posted publicly in an issue, comment, screenshot, or repository fixture should be treated as exposed and revoked if it was ever valid.

Scope

This issue tracks account import only.

It does not define:

• automatic account failover — [Feature]: Generic OAuth account-pool failover with session affinity and quota-aware selection #695;
• Antigravity pool/quota UI — [Feature] Google Antigravity multi-account management, pool health and quota UX #1062;
• Gemini/Claude quota display — [Feature]: add per-account Gem/Cla quota display for Google Antigravity #1082.

Imported accounts should simply become normal Antigravity accounts available to those existing/shared systems.

Acceptance criteria

• Users can import a Cockpit Tools-style JSON array.
• Multiple accounts can be imported in one operation.
• Imported accounts are registered through the normal Antigravity credential/account path.
• Duplicate accounts are handled deterministically.
• Invalid records return actionable per-record errors.
• Full refresh tokens never appear in logs, API responses, diagnostics, or post-import UI.
• A secret-redaction regression test covers the import path.
• Successfully imported accounts are immediately available to the Antigravity account-management and pool systems.