# How to Configure Custom Entry Points for Dead Code Detection in code-graph-rag

> Learn to configure custom entry points for dead code detection in code-graph-rag via CLI or Python API. Improve code analysis accuracy now.

- Repository: [Vitali Avagyan/code-graph-rag](https://github.com/vitali87/code-graph-rag)
- Tags: how-to-guide
- Published: 2026-09-06

---

**You can configure custom entry points for dead code detection in code-graph-rag using the `--entry-point` CLI flag or by passing an `entry_points` tuple to `DeadCodeConfig` when using the Python API.**

The dead-code detector in *code-graph-rag* performs reachability analysis by walking the call graph from a set of root symbols. While it automatically infers entry points from framework hooks, module-load callees, and test code, you can explicitly define your own starting points to ensure critical functions are never flagged as dead.

---

## Using the CLI --entry-point Flag

The `dead_code` command accepts multiple `--entry-point` (or `-e`) arguments. Each value is a **fully-qualified name** (QN) that identifies a symbol to treat as a root.

```bash
code-graph-rag dead_code --entry-point myproj.services.main --entry-point myproj.utils.cleanup

```

In [`codebase_rag/cli.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/cli.py), the option is defined as a list of strings:

```python

# codebase_rag/cli.py – option definition (lines 63-66)

entry_point: list[str] = typer.Option(
    [], "--entry-point", "-e", help=ch.HELP_DEADCODE_ENTRY_POINT
),

```

These values are collected and converted to a tuple in the configuration builder:

```python

# codebase_rag/cli.py – building the config (lines 31-41)

entry_points=tuple(entry_points),

```

---

## How Entry Points Become Roots

During the graph walk in [`dead_code.py`](https://github.com/vitali87/code-graph-rag/blob/main/dead_code.py), each symbol's QN is tested against your supplied entry points. The matching rule uses `str.endswith()`, so you can provide either a **full QN** or a **unique suffix**:

```python

# codebase_rag/dead_code.py – entry-point rule (lines 574-575)

lambda: any(qn.endswith(entry) for entry in config.entry_points),

```

This design gives you flexibility:

- **Exact match**: `myproj.services.main`
- **Suffix match**: `main` (matches any symbol ending in "main")

Any matching symbol is marked as a root, and its entire reachable subtree is considered **live code**.

---

## Programmatic Configuration with DeadCodeConfig

For library usage, construct a `DeadCodeConfig` directly and pass it to `collect_dead_code` or `dead_code_from_graph`:

```python
from codebase_rag.dead_code import default_dead_code_config, collect_dead_code
from codebase_rag.types_defs import DeadCodeConfig

config = DeadCodeConfig(
    include_tests=False,
    include_classes=False,
    root_decorators=frozenset(),
    entry_points=("myproj.services.main", "myproj.utils.cleanup"),
    test_patterns=(),
)
rows = collect_dead_code(ingestor, "myproj", config)

```

The `DeadCodeConfig` named tuple is declared in [`codebase_rag/types_defs.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/types_defs.py) and stores `entry_points` as an immutable tuple, ensuring consistent hash behavior for caching.

---

## Key Source Files

Understanding these files helps you trace how custom entry points flow through the system:

| File | Purpose |
|------|---------|
| [`codebase_rag/cli.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/cli.py) | Defines the `dead_code` CLI command and parses `--entry-point` arguments |
| [`codebase_rag/dead_code.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/dead_code.py) | Implements the reachability engine; contains the `endswith` matching rule at lines 574-575 |
| [`codebase_rag/types_defs.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/types_defs.py) | Declares the `DeadCodeConfig` named tuple that stores configuration |

---

## Summary

- Use `--entry-point` / `-e` in the CLI to add custom roots from the command line
- The matching logic uses `qn.endswith()`, supporting both full QNs and unique suffixes
- For Python API usage, set `entry_points` in a `DeadCodeConfig` tuple
- All entry points feed into [`dead_code.py`](https://github.com/vitali87/code-graph-rag/blob/main/dead_code.py) lines 574-575, where they determine which symbols initiate the reachability walk

---

## Frequently Asked Questions

### What format should I use for entry point names?

Use **fully-qualified names** (module.path.symbol) or **unique suffixes**. Because the detector checks `qn.endswith(entry)`, a suffix like `main` will match `myproj.services.main`, `myproj.cli.main`, and any other symbol ending in "main". For precision, provide the full QN.

### Can I specify multiple entry points?

Yes. The `--entry-point` flag is repeatable, and the `DeadCodeConfig.entry_points` field accepts a tuple of multiple strings. Each entry point is treated as an independent root for reachability analysis.

### Why does the configuration use tuples instead of lists?

Tuples are **hashable and immutable**, which allows `DeadCodeConfig` to be used as a dictionary key and enables reliable caching of analysis results. The CLI automatically converts your list of arguments into a tuple before constructing the configuration.

### What happens if my entry point doesn't exist in the code?

The detector silently ignores unmatched entry points. No error is raised, but the non-existent symbol obviously cannot serve as a root. Verify your QNs match actual symbols in the analyzed codebase, or use suffix patterns that capture your intended targets.