Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

fix(google-antigravity): discoverAntigravityProject fails with missing_project when project is not auto-discovered, rejecting valid tokens

Open
  • Is something wrong?
#7,382 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@yobushka is already working on this.

Since Oct 19, 2026.

  • #7385 by @yobushka — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
typescript
Domain
authentication, backend

Research direction

Start with src/oauth/account-import/google-antigravity-adapter.ts and the discoverAntigravityProject implementation referenced in the issue. Trace how discovery handles loadCodeAssist and onboardUser, then inspect the account import and OAuth parameter paths. Done means valid credentials are accepted when discovery returns no project and the issue’s aicode-consumers scenario works; linked pull request #7385 indicates work is already underway.

Written by the indexing model from the issue text.

Description

account-pool bug
Client or integration
  • OpenCodex dashboard
  • Direct HTTP/API client
Area
  • Authentication and account pool
  • Provider adapter
Version

2.83.0 (commit 33b321853aff76045617824793cc7cbc1d4084e7)

Operating system

Linux (Ubuntu 26.04 LTS / Docker)

Provider and model

google-antigravity

Summary

During Google Antigravity OAuth or account import (createAntigravityAccountImportAdapter), OpenCodex mandates discovery of a Cloud Code Assist projectId via discoverAntigravityProject:

const projectId = await discoverAntigravityProject(creds.access, this.ctrl.signal);
if (!projectId) {
  throw new Error("Antigravity login could not discover a Cloud Code Assist project for this account. Ensure the account has Antigravity/Cloud Code Assist access and try again.");
}

In src/oauth/account-import/google-antigravity-adapter.ts:

if (typeof credential.projectId !== "string" || credential.projectId.length === 0) {
  return { status: "failed", code: "missing_project" };
}

If Google's loadCodeAssist or onboardUser endpoints do not return a project identifier matching the parser's specific expectations (e.g. accounts with existing consumer tiers or established aicode-consumers project mapping), discoverAntigravityProject returns undefined.

As a result, OpenCodex rejects the entire authentication attempt (code: missing_project) and discards the valid refresh token, even though the token works properly when configured with the standard Antigravity project (aicode-consumers).

Reproduction
  1. Attempt an OAuth login or cockpit import (POST /api/oauth/accounts/import) for a Google account whose loadCodeAssist API response does not populate cloudaicompanionProject or matches consumer project configurations.
  2. The authorization exchange succeeds and issues valid access_token and refresh_token.
  3. discoverAntigravityProject runs loadCodeAssist -> fails/returns no recognized key, then runs onboardUser -> returns undefined.
  4. The import/login fails with missing_project / credential_rejected.
  5. If the same refresh token is persisted in auth.json with "projectId": "aicode-consumers", requests to /v1/chat/completions (e.g. gemini-3.8-flash) succeed with HTTP 200.
Expected behaviour
  1. discoverAntigravityProject should fall back to a standard default project ID (such as aicode-consumers) if discovery endpoints do not return an explicit enterprise project.
  2. The account import payload (CockpitAccountRecord) and manual OAuth parameters should allow an optional project_id override so accounts are not rejected outright when discovery fails.
  3. A failed discovery should not discard otherwise valid OAuth credentials.
Checks
  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
7h 34m
Merged PRs (30d)
667

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.