The LinkedIn auto job applier drives your own account with a patched Chrome driver

It uses your account, and the disclaimer hands the terms question back to you

The shape of the project is narrow. It runs entirely on your own computer, using your own LinkedIn account, finds jobs relevant to you, fills in the application questions with optional AI help, and applies using the resume you provide. The README claims it can apply to 100+ jobs in under an hour, which is the project's own figure and not something this article has measured. The privacy claim is about storage rather than transmission: nothing is uploaded anywhere, your details stay in local files, and the control panel is reachable only from your own machine. What decides whether you should run it is the dependency list rather than the architecture. The browser driver it uses is undetected-chromedriver, a ChromeDriver patched so that automated sessions are not identified as automated. A tool that applies as you, from your account, with a driver built to stop the site noticing, is the thing to weigh before any question about speed.

Two ways it touches the machine: a patched driver and synthetic mouse input

The dependency file is short and each line carries a comment explaining itself. Under browser automation there is `selenium`, then `undetected-chromedriver` with the note that it auto-downloads a matching Chrome driver when `auto_manage_driver = True`, then `setuptools`, needed by undetected-chromedriver on some Python versions. Under desktop dialogs and prompts there is `pyautogui`, which moves the pointer and synthesises keystrokes at the operating system level rather than through the browser automation channel. Those two lines are the whole external surface. One means a Chrome process started through a modified driver binary, downloaded at first run to match whatever Chrome you have. The other means the tool can move your mouse while you are using the machine, which is also why the quick start tells you to keep the Chrome window in the foreground and watch the log. Neither is hidden, and neither is reversible after the fact, which is the reason the dry run matters more here than in most projects.

The AI layer answers experience, work authorization and salary for you

The optional AI path is provider-agnostic and pinned exactly, which is unusual next to the unpinned automation packages beside it. `langchain==1.3.14` provides `init_chat_model` and structured output, `langchain-openai==1.4.2` covers OpenAI plus any OpenAI-compatible server and the file names Ollama, LM Studio, DeepSeek and vLLM as examples, `langchain-google-genai==4.3.2` covers Gemini, and `langgraph==1.2.10` does the graph orchestration for what the file calls the question-answer pipeline. The documentation page for the questions configuration lists what gets answered: experience, work authorization, salary, notice period and resume. Two of those are declarations a person makes about themselves to an employer, and they are being answered by a model and submitted under your name on your account. Whichever provider you point at receives those answers as part of the prompt, so the privacy claim about local files does not extend to the model call. That is the one part of this project where the answer quality is not yours to check before it is sent.

The control panel writes JSON and the Python files stay editable, with no stated precedence

There are two ways to configure this tool and the README introduces the second as still working exactly as before. The control panel is a browser page served locally, with tabs for Account, Profile, Search, Filters and Run settings, and what you save there lands in `user_config.json`. The classic path is editing the files under `config/` by hand, and there are five of them, each with its own documentation page: `personals.py` for name, phone, address and equal-opportunity answers, `questions.py` for the Easy Apply answers, `search.py` for search terms, LinkedIn filters, skip rules and visa-sponsorship filtering, `secrets.py` for LinkedIn login and the optional AI setup, and `settings.py` for how the bot runs. So one behaviour is expressed in two stores, a JSON file written by a Flask app and five Python files written by you. The README does not say which one wins when both exist, and `config_schema.py` sitting at the top level is the piece that would have to reconcile them.

The dry run stops at Review, and it is a line in a Python file

There is one control in the documentation that stops the tool from submitting, and the README puts it in a tip for your first run: set `stop_before_submit = True` in `config/settings.py` and the tool will fill in every application and stop at the Review step without submitting, so you can see what it would say before you trust it. The documentation anchors it as a dry run, and the settings page describes that file as covering click gap, background mode, safe mode and dry runs. Two things follow. The dry run is a file edit in a Python module, not a switch in the Run tab of the control panel, and whether the panel exposes the same setting is not stated anywhere in the text. And the dry run stops at the last possible moment rather than earlier: every field is still filled in, including the ones a model answered, so it shows you the exact text that would have been submitted without submitting any of it.

MIT now, AGPL-3.0 for anything released before August 2026

The license section is short and the date in it matters. The project is MIT licensed, copyright 2024 to 2026 Sai Vignesh Golla, and the same section says releases before August 2026 were AGPL-3.0, pointing at a `NOTICE` file for the relicensing history. That `NOTICE` file is at the top level of the repository next to `LICENSE`. So the licence boundary is a date rather than a version number, and it runs through a project's life rather than across its major versions. If you vendored this code, linked against it, or forked it before that month, the copy in your tree was the AGPL and its obligations came with it; if you installed it after, it is MIT. Anyone reading only the repository's licence field sees MIT and nothing about the earlier line, which is exactly the case where the `NOTICE` file has to be read rather than assumed.

Three release tags were pushed within three seconds of each other

The three visible releases are named after dates rather than sequence numbers: v26.08.31 for August 2026, v26.01.20 for January 2026 and v24.11.28 for November 2024. All three carry a publication timestamp inside the same three seconds on 2026-09-10, at 15:40:13, 15:40:12 and 15:40:11. That pattern says the tags were created in one batch rather than cut as each version shipped, so the tag dates tell you when the tags were pushed and not when those releases became usable. Anyone pinning a version from this list is pinning something whose real age the timestamps do not describe, and the project's own release notes page is the place that history lives. The rest of the top level follows the same plainness: a `VERSION` file, `requirements.txt` and `requirements-dev.txt` with no `pyproject.toml` or `setup.py` anywhere, `app.py` for the local history web UI, `runAiBot.py`, `modules/`, `templates/`, `tests/` with `pytest.ini`, three launchers named `start.bat`, `start.command` and `start.sh`, and three test runners named `run_tests.bat`, `run_tests.command` and `run_tests.sh`.

Editorial conclusion

Read the terms question first. This tool automates activity on a LinkedIn account you own, from a browser session the site is built to recognise as automated, and the project itself states that you are responsible for making sure your use complies with the terms of any website or service you use it with. If that is acceptable to you, the tool is at least inspectable: it runs locally, its dependencies are four lines of pinned AI packages plus unpinned Selenium, and there is a documented dry run that fills in every application and stops at Review without submitting. Turn that on before anything else. Then decide whether you want a language model filling in your work authorization and salary answers under your name, check whether your copy predates August 2026 and is therefore AGPL, and keep the three second tag timestamps in mind when you decide which version you are running.

Frequently asked questions

Official sources

1. GodsScion/Auto_job_applier_linkedIn on GitHub
2. Issues
3. License: MIT
4. README
5. Releases