github-farm: a Python OAuth harvesting framework for AI gateways

What github-farm actually automates

The README frames the project as a "modular automation framework" for "scalable identity generation, real-time IMAP OTP capture, and multi-platform OAuth token harvesting." Stripped of the marketing, that means three concrete jobs. First, generating email addresses that all route to one inbox, using Gmail dot-trick or ProtonMail plus-addressing. Second, watching that inbox over IMAP and pulling the one-time password a platform sends during signup, so no human opens a browser. Third, taking the OAuth token that comes back and pushing it into a local AI gateway.

The audience is narrow. The README names AI agents (Hermes, Codex, Claude Code) as first-class callers, and every CLI command supports a --json flag so an agent can parse results instead of scraping stdout. If you are a developer who wants one API key per platform without clicking through three signup forms, this is the tool's stated use. If you want to script GitHub itself, this is not that project, despite the name: the GitHub OAuth flow here is a means of authenticating to Tabi AI, GoRouter and CodeBuddy, not a way to manage GitHub repositories.

The allowance matrix and why the target list is short

The README publishes a table of three platforms, and the table is the most informative part of the document. Tabi AI uses GitHub OAuth and reports a $120.00 USD welcome balance plus $5 to $10 per daily check-in. GoRouter also uses GitHub OAuth and reports $70.00 USD plus the same daily range. CodeBuddy Global uses GitHub Keycloak OIDC and reports 250 bonus credits plus 100 credits per month.

Two things stand out. The signup links carry affiliate parameters, which means the author has a commercial interest in which platforms appear in that table. That does not make the numbers false, but it does mean you should treat the allowance figures as promotional claims from the vendors rather than measured results, because the repository publishes no verification. Second, the list is short and platform-specific. CodeBuddy is the odd one out: it is an OIDC flow through Keycloak, not plain GitHub OAuth, which is why the injection example uses a different platform argument. Any platform not in that table has no documented path through this code.

Installing github-farm and capturing a first OTP

The README gives no pip install or npm install step. The repository has a package.json, but its only script shells out to Python's unittest discovery, and main.py sits at the top level, so the intended entry point is running main.py from a clone. The first documented action is copying the example config into place.

cp config/config.example.toml config/config.toml

With the config in place, the README's first real task is generating email variations. The Gmail dot-trick form takes a username, a domain and a count, and writes the aliases to stdout.

python3 main.py generate --user dannboss --domain gmail.com --type dot --count 20

ProtonMail plus-addressing uses the same command with a different type and domain.

python3 main.py generate --user masterboz --domain proton.me --type plus --count 20

The next step is the OTP listener. It needs the master address and the 16-character Google app password, and the README's example sets a 120 second timeout, after which the command returns whatever it captured.

python3 main.py listen-otp --user your_email@gmail.com --password your_16_digit_app_password --timeout 120

Finally, the harvested token goes into the local gateway. The README's example targets CodeBuddy and takes the raw JWT as a string.

python3 main.py inject --platform codebuddy --token "<RAW_JWT_TOKEN>"

For agent callers, the same commands accept --json. The README shows the generate and listen-otp forms with that flag.

python3 main.py generate --user masteruser --domain gmail.com --count 10 --json
python3 main.py listen-otp --user master@gmail.com --password 16digitapppassword --json

Proxy rules are the real gate on whether this works

The README devotes an entire section to network prerequisites, and it is blunt: GitHub's Web Application Firewall "strictly monitors signup requests for anomaly patterns," and datacenter or commercial hosting ASN proxies from Cloudflare, AWS or DigitalOcean "will immediately trigger WAF restrictions" with the message Access is temporarily restricted. The stated requirement is mobile 4G/5G CGNAT or clean residential ISP proxies, with one clean IP per registration session.

This is the constraint that decides whether the project is usable at all. It is also the constraint the code cannot solve. Nothing in the repository layout suggests a proxy rotation engine; config/ holds a TOML file and that is where the proxy setting presumably lives. So the framework automates the repetitive parts of signup, and leaves the expensive part, a pool of clean residential or mobile egress IPs, entirely to you. Budget for that before you budget for anything else.

Where github-farm breaks or is the wrong tool

Three failure modes are visible from the documentation alone. The first is the proxy rule above: run this from a cloud VM and the README predicts immediate restriction, so any CI or containerized deployment on a hosting ASN is off the table by design.

The second is the OTP dependency. Autonomous capture requires a Google account with 2-Step Verification enabled and a dedicated 16-character app password generated at myaccount.google.com/apppasswords. That is a standing credential with mailbox read access, and the README's own example passes it on the command line, which puts it in shell history and process listings. There is no documented alternative to IMAP app passwords.

The third is operational blindness. The README does not document rollback, token revocation, rate limits, retry behavior or what happens when a platform changes its OAuth flow. There are no releases in the repository metadata, so there is no changelog to read either. If a platform silently changes its signup form, you find out from a failed run, not from a version note. For a framework whose whole job is to keep sessions alive across third-party platforms, that is a real gap, and it is the strongest argument for treating this as a personal automation script rather than infrastructure.

How it compares with browser automation stacks

The obvious alternative is browser automation: Playwright or Selenium driving a real signup form, with a headless browser profile per account. The difference in approach is where the work happens. A browser stack interacts with the rendered page, so it survives form changes by re-recording selectors and it can handle captchas through manual intervention or third-party services. github-farm instead talks to the OAuth endpoints directly and reads the OTP from IMAP, which is faster and far lighter than spinning a browser per signup, but it has no fallback when a platform adds a step that is not part of the OAuth redirect.

A second alternative is doing nothing programmatic: sign up manually for each platform and paste the token into your gateway once. That is genuinely competitive here, because the allowance matrix lists three platforms. Automation pays off at volume, and volume is exactly what the proxy rule makes expensive. If you need five accounts, do it by hand. If you need hundreds and you already operate a residential proxy pool, the framework is the cheaper path.

Licence, maintenance and upgrade cost

The project is MIT licensed, with D4NNBOZ listed as author in both the README and package.json. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained; it offers no patent grant and no warranty. None of that is legal advice, and if you plan to resell access built on this code, the affiliate links in the README and the terms of the three platforms matter more than the licence does.

The last push to the default branch was on 2026-08-20, and the repository is not archived. That is recent enough that the code has not visibly gone stale, but the absence of any tagged release means upgrading means tracking main and reading commits yourself. Because the project depends on three external OAuth providers whose flows can change without notice, the realistic upgrade cost is not pulling new commits, it is re-verifying the flow for each platform whenever a run starts failing. Plan for that as ongoing work, not a one-time install.

Editorial conclusion

Adopt github-farm only if you need scripted signup and session injection across the three platforms its README names, and only if you can supply clean residential or mobile proxies and a Google account with 2-Step Verification and a 16-digit app password. Do not adopt it for general GitHub automation, for CI pipelines on datacenter IPs, or if you need a documented rollback path, because the README does not describe one. Verify three things before writing any code against it: the contents of config/config.example.toml, what src/ actually implements versus what the README advertises, and whether the platform you target still accepts the OAuth flow listed in the allowance matrix.

Frequently asked questions

Official sources

1. d4ncboz/github-farm on GitHub
2. Issues
3. License: MIT
4. README