DorkAgent: no requirements file, one exact crewai version, and customisation that means editing site-packages

The dependency set is installed at startup and recorded nowhere

Usage is two commands:

git clone https://github.com/yee-yore/DorkAgent.git
cd DorkAgent
python dorkagent.py

The program then auto-installs all required packages on first run, prompts for a search engine and an LLM provider, and writes the API keys you type into a `.env` file. So the install step is a side effect of the run step, and the list of what gets installed lives in the code rather than in a file.

The repository root has no `requirements.txt`, no `pyproject.toml` and no `setup.py`. Thirteen entries are present: `.gitignore`, `CLAUDE.md`, `CONVENTIONS.md`, `LICENSE`, `README.md`, six Python modules, `banner.gif` and `example_domains.txt`. That absence has been noted before in the update log. An entry dated 2025-04-01 says a `requirements.txt` was added for Windows and MacOS compatibility, and another dated 2025-08-11 says the requirements file format was restored. Neither file is in the tree now.

The update log is also where the one hard version statement lives: compatibility was fixed for crewai 1.15.17 on 2026-08-24, by switching OpenAI to CrewAI's native wrapper because `ChatOpenAI` is no longer accepted by `Agent`, and by adding the `crewai[anthropic]` and `crewai[google-genai]` extras. A tool written against one exact crewai release, with no file recording that release, cannot be reinstalled to the same state.

Changing the result count means editing a file inside site-packages

The first customisation point is how many hits come back per query, and neither path goes through this repository. Serper is handled by `serper_dev_tool.py` inside `site-packages/crewai_tools/tools/serper_dev_tool/`, where the class carries `n_results: int = 10` with a comment marking the floor at 10 and the ceiling at 100. SerpApi is handled by `serpapi_google_search_tool.py` inside `site-packages/crewai_tools/tools/serpapi_tool/`, and by default it forwards only `q` and `location`, so a `num` key has to be added to the `client.search({...})` call inside `_run()` to change anything.

Two consequences follow. First, the directory you are told to edit is created by the auto-install that happens on first run, so you must run the program once, supply real API keys, and let it mutate your environment before the documented customisation path exists at all. Second, the two engines start from different behaviour: Serper has a result count of ten out of the box, SerpApi has none forwarded, so switching engines changes how much material the agent sees.

There is no `DORKAGENT_` environment variable, no CLI flag and no config entry for either value. `config.py` is named in the update log as the place where search engine selection lives, as `select_search_engine()`, but the result count does not appear in any of the four customisation items.

The search window is hardcoded to a past month in both engines

The second customisation point is how far back the results reach, and the shipped default is the same in both engines: one month.

For Serper the value is a literal inside the request builder, shown here as written:

# https://serper.dev/playground

def _make_api_request(self, search_query: str, search_type: str) -> dict:
    ...
    payload = json.dumps({"q": search_query, "num": self.n_results, "tbs": "qdr:m"}) # Past week: "qdr:w", Past month: "qdr:m"
    ...

For SerpApi the equivalent line has to be added by hand to the search call, because that tool does not forward it by default:

# https://serpapi.com/search-api (tbs param)

results = self.client.search({
    "q": kwargs.get("search_query"),
    "location": kwargs.get("location"),
    "tbs": "qdr:m", # Past week: "qdr:w", Past month: "qdr:m"
}).as_dict()

Both comments name the same two values, past week and past month, and both defaults are the month. Neither is reachable from the command line, and the README offers no environment variable for it. A shorter window narrows what a recon pass can find; a longer one widens the request count against the rate limit that the update log says a setting was added for in 2025-04-17, a setting that appears in neither this list nor any code fence in the file.

Two of the four customisation items are comments containing a URL

The customise section has four numbered items. The first two are the result count and the search window, and both carry real code. The third, Google dorks, is a single fenced line whose whole body is a comment:

# Reference https://github.com/TakSec/google-dorks-bug-bounty

The fourth, agents, is the same shape, a fenced comment pointing at the CrewAI concepts documentation. Neither says which function to edit, where in `tasks.py` the dork list belongs, what the function signature is, or what a valid entry looks like. `tasks.py` and `agents.py` are named only as filenames in parentheses.

So half of the documented extension surface is two outbound links. The first points at an external list of bug bounty dorks rather than at anything in this repository, which means the dork set the agent actually uses is not in the tree and cannot be reviewed from it.

The tree also contains files the README never mentions: `models.py`, `utils.py`, `example_domains.txt` and `banner.gif`. The update log credits `models.py` in the 2025-12-11 entry, which added Pydantic models for structured task output validation, and `utils.py` appears as one of four modules named when the monolithic file was split on 2025-09-29. `example_domains.txt` is named nowhere in the document, so the input file the tool is most likely to want is the one file in the root with no explanation.

Python 3.11.x is a hard floor traced back to one transitive wheel

The requirements section recommends Python 3.11.x and names 3.11.9. The reason given is narrow and concrete: newer interpreters such as 3.13 and up may fail to install crewai's dependencies, `tiktoken` named specifically, because no prebuilt wheel is published for them, so pip falls back to building from source and fails unless a Rust compiler is installed. The remedy given is to switch to 3.11.x if you hit a `tiktoken` build error.

That diagnosis explains one failure and leaves the rest open. The tool has no requirements file, so there is no list of packages to check for the same problem, and the fix is phrased as a response to a specific error string rather than as an enforced constraint. Nothing in the entry point checks the interpreter version, and the documented command is `python dorkagent.py`, not `python3.11`, so whichever `python` resolves to on your shell is the one that runs.

The operating system is never stated in the requirements section, even though an update log entry from 2025-04-01 credits a requirements file with being added for Windows and MacOS compatibility. The install path is a shell `git clone` and the runtime mutates a Python environment on startup, which is a different story on Windows.

The entry point also takes no arguments. There is no flag for the target domain, no `--help`, no batch mode. The domain, the engine, the provider and the keys are all supplied through prompts after the process has started, which means the tool cannot be driven from a script as written.

The update log promises full backward compatibility on one date and a breaking wrapper swap on another

The 2025-09-29 entry describes splitting an 800 line plus monolithic file into a modular architecture of `config.py`, `agents.py`, `tasks.py` and `utils.py`, fixing dependency auto-installation so it happens before module imports, adding timestamps to report filenames in `YYMMDD_HHMMSS` format, and enforcing code conventions with a standardised import order. It closes by claiming full backward compatibility with no breaking changes.

Eight months later, on 2026-08-24, the same file records that `ChatOpenAI` is no longer accepted by `Agent` and that OpenAI was switched to CrewAI's native LLM wrapper. That is a change to the object a caller passes in, so it is breaking for anyone who constructed an agent that way, which is exactly what the compatibility claim rules out.

The module history is also worth tracing. On 2025-04-17 `tasks.py` and `agents.py` were merged into `dorkagent.py` for simpler maintenance, and `tasks(old).py` was deleted. On 2025-09-29 the split was undone by recreating `config.py`, `agents.py`, `tasks.py` and `utils.py`. The current tree reflects the second arrangement, with `models.py` added later.

Nothing records a version anywhere except a changelog line. The 2025-12-11 entry calls the release DorkAgent v1.4, and the repository has no GitHub releases, so v1.4 exists as a phrase in a bullet list with nothing to compare a later checkout against.

Dork coverage was narrowed in April 2025 and widened again in August 2026

Two entries record changes to what the agent will search for, pulling in opposite directions.

On 2025-04-17 the removed items were specific: the dork for finding Confidential documents, on the grounds that most results were merely informative, and the dork targeting login panels. The same entry added settings intended to avoid LLM provider rate limits. On 2026-08-24 the change was the addition of passive OSINT context to the searcher task, given as the reason the agent does not refuse recon on large and well known domains.

Between those two dates the tool also gained runtime engine selection, retry on an invalid API key instead of exiting, and dynamic model selection from available models at runtime, which the 2025-12-11 entry calls v1.4 alongside Pydantic models for structured task output validation.

The net effect for an operator is that the scope of what gets scanned is set by two bullet points in a changelog, separated by sixteen months, in opposite directions, and is not stated in the usage section at all. The only description of scope anywhere in the document is the single line naming the agent as one for automated Google Dorking in bug hunting and pentesting.

There is no statement anywhere about rate limits on the search engines themselves, about how many queries a run issues, or about what happens when a provider key is exhausted. The retry flow added in 2026-08-24 is documented only as retry on an invalid key.

Keys are written to .env on first run and the file is never mentioned again

The program prompts for API keys and saves them to a `.env` file automatically. Which keys depends on two runtime choices. Exactly one search engine key is needed, either `SERPER_API_KEY` from serper.dev or `SERPAPI_API_KEY` from serpapi.com. At least one LLM key is needed, from `OPENAI_API_KEY` for OpenAI models with GPT-4 and GPT-5 named as examples, `ANTHROPIC_API_KEY` for Claude, or `GEMINI_API_KEY` for Gemini.

So the minimum configuration is two keys, one from each category, and the two categories are not symmetric. The engine choice is exclusive and the LLM choice is not: the text says at least one LLM key, while the engine line says one, which reads as exactly one. Nothing in the file states what happens when two engine keys are present and the tool does not prompt you.

The `.env` file is created by the run and is not in the repository listing, so it is presumably ignored, though the ignore rules are not shown. Nothing documents where it is created relative to the working directory, whether it is created if it already exists, or whether an existing key is overwritten. Nothing states whether the file is written in plaintext with no encoding, which for a file holding up to four live API keys is the detail most worth confirming.

Report output is described in exactly one line of the update log, filenames carrying a timestamp in `YYMMDD_HHMMSS` format. The format of a report, the directory it lands in, and whether previous runs accumulate are not stated anywhere in the README.

Editorial conclusion

DorkAgent suits someone experimenting with dork driven recon who already has Serper or SerpApi credentials and does not mind a script that rewrites its own environment. It does not suit CI, reproducible installs, or anyone who needs to know which versions it will pull. Before you run it, decide whether a program that pip installs at startup is acceptable in your environment, expect to patch the search count inside crewai's own installed files if the default ten results is wrong, and treat the missing requirements file as the reason any of this will break later.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. yee-yore/DorkAgent on GitHub