Skip to content

Fix Chrome Web Store submission and Firefox release metadata for v2.7.0 #1051

New issue
New issue
Open
#1091
Open
Fix Chrome Web Store submission and Firefox release metadata for v2.7.0#1051
#1091

Description

@PeterDaveHello
PeterDaveHello
opened on Aug 26, 2026

Summary

The v2.7.0 tagged release successfully built the release artifacts and submitted the extension to Firefox Add-ons and Microsoft Edge Add-ons, but the Chrome Web Store submission failed during OAuth authentication.

The Firefox extension submission itself succeeded, but the Firefox release metadata update did not run because the combined store submission command exited with an error after the Chrome failure.

Chrome Web Store

The tagged-release workflow failed while exchanging the configured Chrome Web Store refresh token for an access token:

[POST] "https://oauth2.googleapis.com/token": 400 Bad Request

{
  "error": "invalid_grant",
  "error_description": "Bad Request"
}

As a result, v2.7.0 was not submitted to the Chrome Web Store. The public Chrome Web Store listing is still on v2.6.1.

This most likely requires access to the Chrome Web Store publisher account and/or the OAuth credentials currently stored in the repository secrets.

@josStorer, could you please help check the Chrome Web Store credentials and either:

  • regenerate/update the Chrome Web Store OAuth refresh token used by GitHub Actions, or
  • manually submit chromium.zip from the v2.7.0 GitHub Release if refreshing the CI credential is not practical?

No credential values should be posted in this issue.

Firefox metadata

The Firefox package submission completed successfully:

[firefox] Submitting new version
Validation results: 0 errors, 27 warnings, 0 notices
✔ Firefox Addon Store

However, scripts/submit-stores.mjs only calls updateFirefoxVersionNotes() after the combined Chrome / Firefox / Edge submission command succeeds.

Since Chrome failed, publish-extension returned a non-zero exit code and the Firefox metadata update was skipped.

This means the v2.7.0 Firefox version may still have stale release notes and compatibility metadata even though the package itself was submitted successfully.

The repository already provides the dedicated Firefox metadata workflow, so v2.7.0 can be repaired independently by running:

Actions → Firefox metadata → Run workflow → version: 2.7.0

This does not resubmit the Firefox extension package.

Follow-up

Separately, the Firefox release-notes URL currently generated by the release script still points to the old josStorer/chatGPTBox repository namespace. That should be fixed independently so future metadata updates point directly to ChatGPTBox-dev/chatGPTBox.

Related release:
https://github.com/ChatGPTBox-dev/chatGPTBox/releases/tag/v2.7.0

Activity

  1. pullfrog commented on Aug 26, 2026

    @pullfrog
    pullfrogBot
    on Aug 26, 2026 – with Pullfrog

    Pullfrog  ｜ Build this ➔ ｜ Make a plan ➔

  2. josStorer commented on Aug 26, 2026

    @josStorer
    josStorer
    on Aug 26, 2026
    Member

    I confirmed that the Chrome Web Store credentials have expired, and the existing publishing API will soon be deprecated. I think I'll re-adapt to the new publishing API and create new credentials in recent days.

  3. josStorer commented on Aug 29, 2026

    @josStorer
    josStorer
    on Aug 29, 2026
    Member

    v2.7.0 has been reviewed and approved for release through manual submission

  4. PeterDaveHello commented on Aug 29, 2026

    @PeterDaveHello
    PeterDaveHello
    on Aug 29, 2026
    MemberAuthor

    Thanks! Let's see if it works in the next release!

  5. PeterDaveHello commented on Sep 6, 2026

    @PeterDaveHello
    PeterDaveHello
    on Sep 6, 2026 – with ChatGPT Codex Connector
    MemberAuthor

    Looks like the same Chrome Web Store issue happened again with v2.7.1:

    https://github.com/ChatGPTBox-dev/chatGPTBox/actions/runs/34048814762/job/101528598376

    The Chrome OAuth token exchange still fails with invalid_grant, while the Firefox and Edge submissions completed successfully.

    Because the combined store submission exits with an error, the final GitHub Release publishing step was skipped, leaving v2.7.1 as a draft. The Firefox metadata update is also skipped for the same reason.

    For now, I'll manually publish the v2.7.1 GitHub Release and run the Firefox metadata workflow for 2.7.1.

    @josStorer, could you please manually submit chromium.zip for v2.7.1 again as a temporary workaround?

    I think we should also decouple GitHub Release finalization and Firefox metadata updates from individual store submission failures, so a Chrome publishing issue doesn't block otherwise successful releases.

  6. hamzahamidi commented on Sep 26, 2026

    @hamzahamidi
    hamzahamidi
    on Sep 26, 2026
    Contributor

    An option for the Chrome step is my publish-to-chrome-web-store action. It uses Chrome Web Store API v2 and accepts a short-lived access token from google-github-actions/auth. With GitHub OIDC and Google Workload Identity Federation, each release can mint a 30-minute token instead of storing CHROME_REFRESH_TOKEN, CHROME_CLIENT_SECRET, and CHROME_CLIENT_ID in Actions secrets. The Google service account still needs access to the Chrome Web Store publisher account. The action also supports dry runs and checks listing and version state before upload. Since release:submit currently handles Chrome, Firefox, and Edge together, Chrome publishing would need its own step while Firefox and Edge remain on their current path. I maintain the action. If this fits the API v2 work, I can prepare an integration PR.

  7. PeterDaveHello
    closed this as completedin #1091on Oct 14, 2026
  8. PeterDaveHello
    reopened this on Nov 1, 2026

  9. PeterDaveHello commented on Nov 1, 2026

    @PeterDaveHello
    PeterDaveHello
    on Nov 1, 2026 – with ChatGPT Codex Connector
    MemberAuthor

    Reopening to track the remaining Chrome publishing setup after #1091.

    For v2.7.2, attempt 2 completed the macOS build, published the GitHub Release, and successfully submitted to Firefox and Edge, including the Firefox metadata update. Chrome failed before its upload step in publish_chrome:

    the GitHub Action workflow must specify exactly one of "workload_identity_provider" or "credentials_json"!

    The auth step did not receive workload_identity_provider or service_account, which the workflow reads from vars.CWS_WIF_PROVIDER and vars.CWS_SERVICE_ACCOUNT. The logs do not establish whether those values are missing or stored outside the job's accessible scope.

    @josStorer, could you or another maintainer with access to the existing Chrome Web Store publisher and the Google Cloud project help complete/verify the external setup documented in #1091?

    • Confirm the WIF provider and service account exist, with the intended repository/release-tag grants, and link the service account to the existing Chrome publisher.
    • Set CWS_WIF_PROVIDER, CWS_SERVICE_ACCOUNT, and CWS_PUBLISHER_ID in Actions Variables, and confirm CHROME_EXTENSION_ID is available as a secret to publish_chrome in the chrome-web-store environment.

    After that, only re-run the failed publish_chrome job; the other release steps have already completed. If the Google setup cannot be completed yet, please manually submit chromium.zip from the v2.7.2 release as an interim workaround. If another maintainer now manages the publisher, please point us to them.

  10. hamzahamidi commented on Nov 1, 2026

    @hamzahamidi
    hamzahamidi
    on Nov 1, 2026
    Contributor

    I checked this against LabelQuick's successful Chrome submission. It submitted 0.2.0 and returned PENDING_REVIEW using the exact same commits of google-github-actions/auth (7c6bc770dae815cd3e89ee6cdf493a5fab2cc093) and my publishing action (c8919147f8de0d6f1129bec36345e4a9aa638af9) as this release.

    In this job, both auth inputs are empty, so it stops before requesting a Google token. The publishing action never starts. The remaining work is to configure and validate ChatGPTBox's own identity and publisher access:

    1. GitHub variables: check CWS_WIF_PROVIDER, CWS_SERVICE_ACCOUNT, and CWS_PUBLISHER_ID under Actions Variables, not Secrets. The workflow reads vars.*. Organization variables must allow this repository; environment variables must be in chrome-web-store. Keep CHROME_EXTENSION_ID as an accessible secret.
    2. Google trust: configure the provider for ChatGPTBox's owner ID 214326765, repository ID 614258120, refs/tags/v* releases, and the chrome-web-store environment. Grant the corresponding repository principal roles/iam.workloadIdentityUser on the service account. LabelQuick's provider and grants are repository-specific, so copying its values would not work. The commands are in the WIF setup guide.
    3. Publisher access: link the intended service-account email under Account in the existing Chrome publisher's dashboard. Google permits one linked service account per publisher, so check the existing linkage first.
    4. Environment restrictions: the chrome-web-store environment currently reports no deployment restrictions. Restrict it to release tags matching v*. This is separate from the empty-input failure.

    I don't have access to this repository's variables or its Google/publisher setup, so those values remain unverified. @josStorer, could you or the current publisher owner check these? Once configured, only the failed Chrome job needs a rerun:

    gh run rerun 41237475808 \
  --repo ChatGPTBox-dev/chatGPTBox \
  --job 124765783732
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions