# Does Holehe Have a Dry Run Mode?

> Discover if Holehe offers a dry run mode. Learn why this OSINT tool performs live network requests for every email check.

- Repository: [Palenath/holehe](https://github.com/megadose/holehe)
- Tags: how-to-guide
- Published: 2026-08-16

---

**No, holehe does not have a dry run mode.** The open-source OSINT tool always performs live network requests to check email registration status across supported services.

Holehe is a command-line utility developed by megadose that checks whether an email address is registered on various websites. While it offers several flags to customize execution behavior, the codebase contains no mechanism to simulate or preview operations without contacting external services. Understanding this limitation is essential for users testing the tool or operating in restricted network environments.

## How Holehe's CLI Arguments Work

The command-line interface in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) defines a fixed set of arguments. Examining the source code reveals no hidden dry-run functionality.

### Available Flags in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py)

The argument parser (approximately lines 80-96) exposes these options:

| Flag | Short | Purpose |
|------|-------|---------|
| `--only-used` | — | Display only sites where the email is found |
| `--no-color` | — | Disable colored terminal output |
| `--no-clear` | — | Prevent clearing the screen before displaying results |
| `--no-password-recovery` | `-NP` | Skip password recovery attempt checks |
| `--csv` | `-C` | Export results to a CSV file |
| `--timeout` | `-T` | Configure HTTP request timeout (default: 10 seconds) |

**None of these flags prevent network requests.** Even `--only-used` still queries every module; it simply filters the output presentation.

### The `launch_module` Execution Path

Every service check flows through `launch_module`, which unconditionally executes:

```python

# Simplified structure from holehe/core.py

async def launch_module(module, email, client, out):
    # Always performs the actual HTTP request

    await module(email, client, out)

```

This architecture means module execution and network I/O are inseparable. There is no conditional branch to skip the `await module(email, client, out)` call based on a configuration flag.

## Verifying Absence of Dry-Run Functionality

A comprehensive search of the repository confirms no dry-run implementation exists:

- **No `--dry` or `--dry-run` argument**: The `argparse` configuration in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) lacks any such option
- **No "dry" string matches**: Case-insensitive search across Python files returns no relevant results
- **No documentation references**: The [`README.md`](https://github.com/megadose/holehe/blob/main/README.md) describes all available flags without mentioning simulation modes
- **No test mode**: Searching for "test" or "example" flags yields no alternative execution paths

## Practical Implications for Users

Since holehe lacks dry-run capability, consider these operational realities:

### Network Traffic Is Unavoidable

Running `holehe example@example.com` will always generate outbound HTTPS connections to every supported service. For users with:

- **Metered connections**: Data usage scales with the number of modules (~100+ services)
- **Corporate proxies**: All requests traverse your network infrastructure
- **Rate-limited environments**: Repeated executions may trigger IP blocks

### Minimal Risk Mitigation: The `-NP` Flag

The **no-password-recovery** flag reduces query complexity without eliminating network traffic:

```bash

# Standard execution with full checks

holehe target@example.com

# Skip password recovery endpoints only

holehe target@example.com --no-password-recovery

# Combined with other output options

holehe target@example.com -NP --only-used --csv results.csv

```

Even with `-NP`,holehe still performs registration existence checks via live API calls and webpage scraping.

## What a Dry-Run Mode Would Require

Implementing true dry-run functionality would require structural changes to [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) and all service modules:

1. **Argument extension**: Add `--dry-run` to the parser
2. **Module interface modification**: Pass dry-run state to each service checker
3. **Request interception**: Replace `httpx.AsyncClient` calls with mock responses or logging stubs

As of the current implementation, no such abstraction layer exists. The modules directly embed HTTP logic without injection points for simulation.

## Summary

- **Holehe has no built-in dry run mode** — every execution performs live network requests
- **CLI flags control output formatting and check scope**, not network behavior
- **`launch_module` in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) unconditionally executes HTTP calls** through each service module
- **The `-NP` flag only skips password recovery checks**, not registration verification
- **Users requiring network isolation must modify source code** or use external traffic interception tools

## Frequently Asked Questions

### How can I test holehe without making real requests?

You cannot using the official distribution. The tool is designed for live OSINT operations. For testing purposes, you would need to either: fork the repository and modify [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) to inject mock responses, or intercept traffic at the network level using tools like `mitmproxy` with recorded responses.

### Does holehe cache results to avoid repeat queries?

No. Each invocation of holehe performs fresh HTTP requests to all targeted services. There is no disk-based or memory-based caching mechanism in [`holehe/core.py`](https://github.com/megadose/holehe/blob/main/holehe/core.py) or the modules directory. Results are computed in real-time and discarded after output generation.

### What is the purpose of the `--only-used` flag?

The `--only-used` flag filters the terminal output to show only successful matches — sites where the email is registered. However, this filter applies **after** all network requests complete. The flag does not reduce the number of services queried or prevent any HTTP traffic.