A job-search agent that stops at CAPTCHAs instead of beating them

A job-search agent that never sends anything without you looking first

BossHunter is a local-running agent that automates the repetitive parts of a concentrated job search across several major Chinese recruitment platforms, collecting listings, scoring them with AI against your own resume, drafting personalised opening messages, monitoring recruiter replies, and generating tailored resumes on request. The README states its purpose in one sentence worth taking seriously: it helps someone searching intensively reduce repeated searching, filtering and communication preparation, while the final decision to apply stays with the person, and no application is ever sent without having first been confirmed by a human.

That mandatory confirmation step is stated as a hard rule rather than a configurable option, and it is the single design decision the rest of the project is built around. A tool that automates job applications end to end, with no human checkpoint, is a tool one bad AI judgement call away from spamming recruiters with irrelevant applications under your name. Requiring a person to review and approve every application before it goes out, individually or in a batch, keeps the actual application decision where it belongs while still automating the tedious search, scoring and drafting work leading up to that decision.

An honest warning at the top, not buried in fine print

Directly under the introduction, before any feature is described, the README places a warning in its own visually distinct callout: automating interaction with recruitment platforms carries a real risk of account restriction or banning, the project is intended only for learning, research and improving one's own job-search efficiency, users must follow each platform's rules and keep usage infrequent, and the risk of use is the user's own to bear. The same warning states the project has no affiliation, partnership or endorsement relationship with any recruitment platform or its associated companies.

Placing that risk statement first, in a visually marked callout rather than in a distant legal section, is the responsible way to publish automation software for a platform whose terms of service were not written with this kind of tool in mind. It sets the right expectation before a reader gets excited about the feature list, and it is consistent with the behaviour described later in the README, where the actual automation is built to stay well inside that stated risk tolerance rather than to push against it.

A capability table that tells you exactly what is automated and what is not

Rather than claiming uniform automation across every supported platform, the README publishes a capability table drawing a clear line platform by platform. One platform supports full automation: collection, AI scoring, and low-frequency sending after human confirmation, with reply monitoring. The other three platforms supported are explicitly read-only for collection, scoring and message drafting; actually applying happens manually on the original platform, and the user then marks the listing as sent back in BossHunter's own tracker.

That asymmetry is a deliberate and sensible constraint rather than an unfinished feature. Automating the actual sending step is the highest-risk part of interacting with any platform, since it means the tool is taking an action on the user's account rather than only reading and preparing material, and building that specific capability for every platform at once would multiply the account risk across four separate services simultaneously. Limiting automated sending to one platform, while still delivering the time-saving collection and scoring work everywhere, is the kind of scoped ambition that keeps a project's risk surface proportionate to what it has actually verified works safely.

When it hits a wall, it stops, and says so explicitly

The README states plainly that collection across every platform runs strictly one at a time, and that when the agent detects a CAPTCHA, a rate limit, a login wall, or an unrecognised page structure, it safely stops rather than attempting to work around the obstacle.

Stopping rather than trying to bypass a CAPTCHA or a login wall is the correct behaviour, and it is worth being explicit about why that distinction matters. A CAPTCHA exists specifically to distinguish a human from automated traffic; an automation tool that tries to defeat one is attempting to circumvent a control the platform put there on purpose, which is a materially different thing from a tool that recognises the control, stops, and leaves the human to handle whatever comes next themselves. The same logic applies to an unrecognised page structure, which most often means the platform changed its layout, and continuing to click blindly against a page the tool no longer actually understands is how automation scripts end up taking wrong or damaging actions. Stopping safely at exactly the points where continuing would mean either evading a platform control or acting on a misunderstanding of what is on screen is the behaviour of a tool built to respect the platform's boundaries rather than to test them.

Setup, and where your resume and API key actually live

Getting started needs Python 3.10 or newer, Node.js 22 or newer, a current version of Chrome, and access to an AI service of your choice:

git clone https://github.com/shengjidaguai-china/BossHunter.git
cd BossHunter
npm --prefix src/bosshunter/web/frontend ci
npm --prefix src/bosshunter/web/frontend run build
pip install -e .
bosshunter web

The local panel that opens is where a user uploads their actual resume, sets job criteria, and connects an AI service, and the README is specific and direct about where that connection information should and should not go: the API key is entered only in the local panel, and must never be sent in chat, in an issue, or committed into a file. That is a reasonable and necessary instruction for a project maintained through public GitHub issues and pull requests, where a support request pasted with a live credential attached is an entirely realistic way for a key to leak. After setup, Chrome remote debugging is enabled and the user logs into the recruitment platform in that same Chrome window before running a connection check and starting the agent, and the README notes specifically that the connection check only verifies connectivity, it does not launch Chrome or log in on the user's behalf.

What to weigh before running it

Licensing is stated in the description rather than left implicit: the project is source-available under the PolyForm Noncommercial licence, with commercial use requiring separate written authorisation, which is a meaningfully different arrangement from an open-source licence and worth understanding correctly before assuming the code can be repurposed freely. The repository's own licensing metadata reports no assertion of a recognised standard licence, so the licence file itself, rather than any badge, is the thing to read directly. This is not legal advice.

Governance here is unusually formal for a project this size, with a named maintainer team, a documented pull-request review process, and an explicit rule that a maintainer's own submitted or co-written technical change cannot be self-approved, with high-risk changes requiring approval from two different maintainers who were not the author. That level of review discipline, applied to a tool that automates interaction with real recruitment accounts, is the right amount of caution for exactly this category of software, where a careless merge could translate directly into a user's account getting flagged.

The project reports 1,020 stars, 145 forks and 33 open issues, with the last push on 2026-09-15, so it is active and drawing real usage. Before running it, three steps in order. Read the warning callout and decide for yourself whether the account-risk tolerance it describes matches your own comfort level. Keep your AI API key inside the local panel exactly as instructed and never paste it anywhere public. And treat the capability table as the actual scope of automation per platform, expecting to manually apply and mark listings as sent on three of the four supported platforms rather than assuming uniform automated sending everywhere.

Editorial conclusion

BossHunter fits someone running a concentrated job search who wants the repetitive collection, scoring and message-drafting work automated while keeping the actual application decision in their own hands, and its hard requirement that every application be confirmed by a human before sending is the design choice that makes that trust reasonable. Its behaviour at the platform's own boundaries, stopping safely rather than attempting to bypass a CAPTCHA, rate limit or login wall, and limiting automated sending to a single platform while the others stay read-only, shows a project built to respect the limits recruitment platforms set rather than to test them. Read the warning callout and decide your own risk tolerance before running it, keep your AI API key inside the local panel exactly as instructed, and expect to manually apply and mark listings as sent on three of the four supported platforms rather than assuming automated sending works everywhere.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. shengjidaguai-china/BossHunter on GitHub