BossHelper: a browser extension that automates job applications, and what it costs

What the project does, and the caution above it

BossHelper is a browser extension for a Chinese job board, described in the repository as a Boss Zhipin assistant whose purpose is to reduce the annoyance of submitting resumes and raise the efficiency of doing so. The feature list in the project description covers UI cleanup and ad removal, batch resume submission, advanced filtering, automatic greetings with GPT, and multi-account management.

Above all of that sits a caution block that is unusually direct for a project of this kind. It states that the project is for learning and exchange only and that commercial use is prohibited, and it warns that using the script carries risk such as having your account blackened, being banned, or having your ranking weight reduced. The project states that it accepts no responsibility.

That paragraph is the most useful thing in the README, because it tells you what kind of tool this is. Nothing here hides that automating a platform at volume is a behaviour its owner can detect, and that the cost of detection falls on the user rather than on the extension author. Anyone evaluating this should read that block as a design constraint rather than as boilerplate.

The distribution table reinforces the picture. The extension is published to the Chrome Web Store, to the Edge Web Store, to the Firefox add-on directory, and as a GitHub build, with a note that users in China who cannot reach the Chrome store should use a third-party Chrome extension mirror site or the Edge store instead.

The project also states that it is actively maintained and that open-sourcing was delayed while the author was busy.

Four stores, two identifiers, and why that matters

The store table carries a detail that only shows up when you read the links rather than the badges: the Chromium and Edge listings are different extensions with different identifiers.

The Chrome Web Store link and the Crx mirror both point at an id beginning ogkmgjbagackkdlcibcailacnncgonbn, while the Edge Web Store listing resolves a product by a different identifier, jcllnbjfeamhihjpfjlclhdnjmggbgal. Firefox has its own listing with the human-readable slug boss-helper.

Two identifiers for the same code is normal for cross-browser extensions, and it is not a red flag on its own. It does mean the permissions model and the update channel differ per store, and it means a user installing from two browsers is running two independently updated copies. For an extension that automates an account, that difference is worth noticing: one copy can be updated for behaviour fixes while the other stays on an older build.

The Firefox listing is also built differently in the source. The build scripts include an explicit Manifest V3 flag for Firefox, which Firefox requires and Chromium does not use in the same way, so the three builds are not the same bundle with different manifests.

The mirror store deserves a sentence of its own. Pointing users at a third-party extension site is a practical answer to a real access problem, and it is also the point in this distribution chain where you are trusting a party that is not the browser vendor. For an extension that reads and submits your applications, that is a decision to make knowingly rather than by convenience.

The stack, and a description that has drifted

The technology stack is stated in the project description as WXT, Vue 3, NuxtUI 4 and Tailwind CSS 4, and the repository contents support it.

The top level carries wxt.config.ts as the extension configuration, tsconfig.json, components.d.ts and auto-imports.d.ts for generated types, oxlint.config.ts and oxfmt.config.ts for linting and formatting, a husky directory with lint-staged in the toolchain, and a packages/ directory wired as npm workspaces with a bun.lock file at the root. There is also a net-conf.json, a docs directory with screenshots, and a scripts directory.

The dependency list confirms the front end and shows what the features are built on. Vue at 3.5.41 and Tailwind at 4.2.4 cover the interface, with Nuxt UI at 4.10.0 as the component layer. @vueuse/core and its integrations package provide composables. For the AI features there is the ai package at 7.0.58 with @ai-sdk/openai at 4.0.36, which is the Vercel AI SDK wired to an OpenAI-compatible provider, plus partial-json for streaming partial output and spark-md5 for hashing.

Two dependencies are less obvious. idb at 8.0.3 is a promise wrapper around IndexedDB, so configuration and history live in the browser rather than on a server. And mqtt at 5.15.2 means the extension talks over MQTT, which the acknowledgements section links out to as the protocol specification. That is an unusual choice for a browser extension and worth understanding before you install it, so a broker is involved somewhere.

One inconsistency: the package.json description still says the stack is Vite, Vue 3 and element-plus, which is the older wording before the move to WXT and Nuxt UI. The description field is simply stale, and the actual scripts confirm the newer stack.

Build scripts: three browsers, one command

The npm scripts are the clearest documentation of how the project is developed.

Development runs through WXT, with a dev script for the default target and two variants, dev:edge and dev:firefox, the latter passing an explicit Manifest V3 flag. A postinstall step runs wxt prepare, which is the command that generates the type scaffolding a WXT project relies on.

The build is the part worth noting. Instead of one target, the build script runs three in parallel with npm-run-all: build:chrome, build:firefox with the MV3 flag, and build:edge. The zip scripts mirror that structure, producing three distributable archives.

So a full release is three builds and three archives, which matches the four distribution channels once you count the GitHub build. That is a modest amount of ceremony for a small team, and it is the price of supporting three stores.

Quality tooling is modern and specific. The check script runs vue-tsc with no emit, so type errors fail without producing output. Linting uses oxlint with a type-aware flag, and formatting uses oxfmt, with a separate check mode. A prepare script runs husky, so git hooks are installed, and lint-staged is in the toolchain. openapi-typescript appears in the development dependencies, so at least part of the data model is generated from an API schema.

The package version is 0.5.2.2, which is worth noting because the published builds are numbered 0.5.2 and 0.5.1, with 0.5.0-2 before them. The extra segment in the manifest is consistent with using the fourth field for store-specific packaging, so the manifest version and the store version are not always the same string.

Reading the TODO as a feature map

The TODO list is more informative than a feature list, because it shows what is finished, what was abandoned and what has not been started.

Completed items include the UI cleanup and ad removal, batch resume submission, basic filtering on salary, company name, job title, headcount and content, and AI-based screening of listings. Distance and travel-time filtering by driving and walking is done, built on the Amap API, which the README notes you have to apply for yourself, with a keyword-based filter as an alternative.

Under automatic greetings, the template language and ChatGPT support are checked. Under AI features, multi-model management is done.

Then the lines that matter for anyone reading this before installing. Automatic replies in chat are not done. A blacklist is not done. Chat read-receipt blocking is not done. A boss message popup is not done. And company risk scoring is listed as unfinished.

The most revealing entry is multi-account management, which is marked done and then annotated as deprecated, replaced by switching between configurations. That is an unusual and honest thing to leave in a TODO: it tells you that running several accounts was tried, judged a liability, and replaced with something narrower.

So the tool that exists today is a fast filter-and-submit machine with model-written greetings. The conversational features, which are the ones that would cross furthest into pretending to be a person, are the ones not built.

The README also points to an older 0.2 version on Greasy Fork, and lists two similar projects, which frames the alternatives.

What the manifest scripts say about shipping three builds

The script block is short enough to read in full, and it is the most reliable description of the project's process:

"build": "run-p build:chrome build:firefox build:edge",
"build:firefox": "wxt build -b firefox --mv3",
"zip": "run-p zip:chrome zip:firefox zip:edge",
"check": "vue-tsc --noEmit",
"lint": "oxlint --type-aware",
"fmt": "oxfmt",
"postinstall": "wxt prepare"

Two things stand out. The postinstall step regenerates the project's type scaffolding on every install, which is the WXT convention and explains the auto-imports and components declaration files at the repository root: they are generated, not hand-written, so they should not be edited by a contributor.

The second is that formatting and linting are separate tools with separate commands. oxfmt owns formatting and oxlint owns linting with a type-aware mode, and fmt:check exists so a pipeline can verify formatting without rewriting files. That pairing is a deliberate choice over a single tool that does both, and it means a contributor has to run two commands before pushing.

The husky prepare script is what makes that stick. Git hooks are installed on install, and with lint-staged in the toolchain, staged files are checked before a commit lands. For a project accepting pull requests from strangers, that is the difference between a clean history and a review that is mostly whitespace.

Where this extension is the wrong tool

There are three boundaries, and the first two are structural rather than fixable.

The first is the account risk, which the project itself names: blacklisting, bans and reduced ranking weight. Automating bulk actions against a platform is exactly the class of behaviour that a platform detects and penalises, and the extension has no way to absorb that cost. A user who is job hunting is also a user for whom a ranking penalty is expensive, which makes this a case where the tool's value and its risk are highest for the same person.

The second is maintenance against a hostile surface. The extension works by interacting with another site's interface, so it breaks whenever that interface changes, and it must change again whenever the site notices. The Chrome and Edge listings under one identifier with periodic builds tell you the author is shipping updates; they also tell you that the work is continuous and reactive rather than occasional.

The third is privacy and data flow. Configuration and history live in the browser through IndexedDB, which is local and inspectable, but the AI features go through an OpenAI-compatible provider, and the MQTT dependency points to a broker the extension connects to. The README includes a privacy policy file and an anonymous feedback form, but it does not describe what is sent to the model provider or to the broker. For a job search, employer names, salary expectations and filter criteria are not neutral data.

Finally, support is one person. There is a Telegram group as the only discussion channel, with WeChat and Feishu ruled out, and the README says each submitted form triggers a notification with a reply in one to two days. That is a generous commitment for one maintainer, and it is not a service level.

Editorial conclusion

Adopt BossHelper if you are applying to a large number of roles on that job board and the bottleneck is clicking, since batch submission, advanced filters and templated greetings address exactly that, and the multi-config switch is a sensible replacement for multi-account juggling. Do not adopt it on an account you cannot afford to lose, because the project states plainly that use carries the risk of a blacklisted account, a ban or reduced ranking weight, and offers no remedy when a platform changes its DOM or its policy. Verify four things. Read the caution at the top of the README before anything else, and treat the stated risks as design consequences rather than marketing disclaimers. Install from a store you trust, since the same extension is published under two different identifiers for Chromium and Edge plus a separate Firefox build, and a mirror store exists for users who cannot reach the official one. Decide which features you actually want, because the TODO shows multi-account management was deprecated in favour of switching between configurations, and automatic chat replies and read-receipt blocking are still unchecked. And check where your conversation data goes, since greeting templates are generated through an AI SDK integration, which means your filter criteria or employer names may reach a model provider. Start with the configuration screens and the card status view before enabling any bulk action.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Ocyss/boss-helper on GitHub
4. README
5. Releases