free-account-tool: a Manifest V3 Chrome extension for bulk account registration and GCash eligibility checks

What free-account-tool actually automates

The extension targets a narrow job: creating and maintaining batches of accounts through a browser, then recording whether each one has GCash trial eligibility. It is a side-panel driven tool for people who already own the email infrastructure it talks to. The repository ships provider adapters for several mail backends, including CloudMail, Hotmail, iCloud, LuckMail, MoeMail, Outlook Plus, YYDS Mail and a 2925 variant, plus a Cloudflare temporary email helper. That list is the clearest statement of audience: you are expected to bring mailboxes or temporary-address services, not to have the extension create them for you.

The account model is deliberately binary at the UI level. Results land in either a Free group or a no-eligibility Free group. The README is explicit that only a server response of ineligible moves an account into the second group, while eligible, unknown, checking and failed all stay in Free. That asymmetry matters more than it first appears. A failed check is not treated as a disqualification, so a broken run does not silently discard accounts.

Version 3.0.0 is a subtraction release. The built-in UPI, IDEAL and PIX card pools, CDK redemption, redemption tasks, the Plus group and their backend interfaces were removed. Old data is migrated once on first startup: account identity, credentials, validity and explicit eligibility evidence survive, while CDK, redemption and Plus classification data are dropped. The two sidebar entries labelled for GCash eligibility lookup and CDK redemption now only open new tabs at gcash.20000408.xyz and cdk.334401.xyz. The README states those entries do not pass account credentials to the websites.

The nine-step flow and where credentials live

Registration follows one fixed nine-step workflow shared by three routes: full 2FA, 2FA-free Free, and Passkey. Step 9 writes the current account credentials, the AT or Session, and trialEligibilityStatus=unknown into the account lifecycle and freeAccountResults, then ends the round. Automatic registration does not call the GCash eligibility endpoint at all. That is a real design decision: eligibility checking became a manual, on-demand action rather than part of the signup path, which keeps the registration flow from depending on a second service being up.

State is split between two storage areas. User configuration has chrome.storage.local as its single authoritative source, and the README warns that a stale Session runtime snapshot must not overwrite saved routes, interfaces, wait times or email provider after a browser or service worker restart. Short-lived state such as flow nodes stays in Session. High-frequency logging and ordinary settings updates read and write only the Session fields they need, rather than loading the full account result set, which the README frames as a way to reduce stalls in resource-constrained fingerprint browsers when the account list is large.

The manifest declares unlimitedStorage so that large volumes of full Sessions, Free results and canonical account records do not hit the default chrome.storage.local quota. The README notes one specific failure path: if the final save node hits a storage quota error, only that node is retried, and the 2FA-free route is not rolled back to step 7. Manual eligibility rechecks submit the ChatGPT AT plus check_gcash_pm=true with a separate Bearer token, and the eligibility service reaches OpenAI through a server-side proxy rather than inheriting the fingerprint browser profile's local proxy.

Two operational details are worth flagging. While automatic registration is running, the account panel is view-only and export-only, so import, delete, login, AT edits and rechecks cannot race the running flow. Session backfill tasks store only the email list, index and count in task data; passwords, 2FA secrets, verification codes, cookies, ATs and Sessions are kept out of the task repository and event log.

Installing free-account-tool from the release archive

There is no Chrome Web Store listing in the README. Installation is the unpacked-extension route, using either a release archive or the current source directory for development. The README gives the steps directly.

# 1. Download and extract the release archive, or use the source directory
# 2. Open chrome://extensions/
# 3. Enable Developer mode
# 4. Click "Load unpacked" and select the extension directory
# 5. After updating code or replacing files, click Reload on the extensions page

After the first load you fill in your own email provider and runtime configuration in the side panel. The README states the release package contains no local accounts, passwords, Access Tokens, cookies, API keys, run logs or browser configuration, so nothing is pre-seeded. The GCash authorization token issued by the eligibility service is only needed when you manually run an eligibility recheck; it is not a ChatGPT AT and does not enter the security configuration export.

For development or to verify a build yourself, the repository defines the following npm scripts. They are documented as PowerShell examples in the README.

npm ci
npm run syntax
npm test
npm run docs:check
npm run audit
npm run e2e

npm run e2e uses a separate Chrome for Testing instance with a temporary profile and does not attach to your everyday Chrome. Packaging is a separate, release-only step.

npm run package

The build script collects only runtime whitelist files; development docs, tests, local configuration, logs and the release directory are excluded from the extension package. The only declared devDependency is puppeteer, which is what backs the e2e run.

Where the extension gets in your way

The most concrete limitation is the migration. First startup after upgrading to V3 performs a one-time conversion that deletes CDK, redemption and Plus classification data. If you were relying on the extension as the system of record for redemption history, that history is gone, and the README offers no rollback path for the migration. The top CDK entry becomes a plain link to an external site. Anyone whose workflow was built around in-extension redemption should treat V3 as a different tool.

Second, the extension is not self-contained. It needs email provider credentials or temporary-address services, and eligibility rechecks need a Bearer token from a third-party eligibility service. The README does not describe who operates that service, what its uptime is, or what happens to the AT submitted with check_gcash_pm=true beyond the statement that the service calls OpenAI through a server-side proxy. That is a trust boundary you accept or you do not.

Third, the UI is intentionally restrictive during a run. View and export only, no imports, deletes, logins, AT edits or rechecks while registration is active. If your process is interactive, this will feel locked down. It exists to prevent state races, but it also means you cannot correct a bad import mid-run.

Finally, the documentation set is heavy on internal engineering rules. The README's core-rules list reads like a set of invariants written for maintainers, and the two CODEX files are described as historical engineering baselines that no longer define behaviour. A new user looking for a quick start will find the nine-step workflow and the two-group model in docs/USER_GUIDE.md, but the README itself is not a tutorial.

free-account-tool versus a general browser automation stack

The obvious alternative is a general automation stack such as Puppeteer or Playwright driving a real Chromium profile. The difference is where the state lives. A Puppeteer script keeps accounts, sessions and eligibility results in whatever you build around it, and every restart is your problem. free-account-tool puts that state in chrome.storage.local with a declared unlimitedStorage quota, splits configuration from Session runtime snapshots, and serialises saves through a single queue so that the side panel's Save button and the settings change events cannot interleave. It also gives you resumable Session backfill: the task stores only the email list, index and count, saves each account as it logs in, can be stopped, and can continue after a service worker interruption, then downloads a Session TXT for the accounts that succeeded.

What you give up is flexibility. The nine-step workflow is fixed, the three registration routes share it, and the sidebar exposes specific actions rather than a scripting surface. A Puppeteer harness can be pointed at anything; this extension is pointed at one account type and one eligibility question. If your target changes shape, you are editing extension code and reloading it, not rewriting a script.

A second alternative is simply not automating: use the provider's own bulk tooling and check eligibility by hand. That is slower but removes the third-party Bearer token and the external eligibility service from your trust surface entirely.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-08, the same day v3.0.0 was tagged. Releases are frequent and versioned: v2.2.0 on 2026-07-26, v2.3.0 on 2026-07-29, v3.0.0 on 2026-08-08. The jump from 2.3.0 to 3.0.0 is the one that removes features, so the upgrade cost is front-loaded rather than spread across minor releases.

The licence is MIT, declared in package.json and present as LICENSE at the repository root. MIT permits commercial and private use, modification and redistribution with the licence and copyright notice retained. That is the general shape of the licence, not legal advice for your situation. Note that the extension talks to third-party services, and those services carry their own terms, which the MIT licence says nothing about. THIRD_PARTY_NOTICES.md exists in the repository for the bundled dependencies.

Upgrade cost after V3 is mostly re-verification. The README states that if an older version mistakenly nested run state into Free account rows, reloading the extension automatically compacts and repairs it while preserving passwords, 2FA or Passkey data, AT, Session and eligibility evidence. The package.json check script chains syntax, unit tests, the documentation audit and the smoke, removed-network and no-phone-SMS audits, so a maintainer can reproduce the project's own gate locally. What the README does not document is a downgrade path from V3 back to V2 data.

Editorial conclusion

Adopt free-account-tool only if you are comfortable with an unpacked Chromium extension that drives registration flows with your own email providers and credentials, and you accept that the CDK and UPI redemption logic now lives on external sites rather than in the extension. Skip it if you need a supported, store-distributed tool, or if your accounts are not GCash-relevant. Before loading it, read docs/USER_GUIDE.md for the nine-step workflow and docs/DEVELOPMENT.md for the V3 migration rules, then run npm ci and npm run check against the tagged v3.0.0 source so you are packaging the same code the release notes describe.

Frequently asked questions

Official sources

1. Issues
2. kui123456789/free-account-tool on GitHub
3. License: MIT
4. README
5. Releases