In the sprawling codebases of modern AI infrastructure, dead code is a known nuisance, but dangling references to deleted files are a subtle rot that static analysis often misses. A new open-source tool called 'ouija', built for the Hacktoberfest Open-Source AI Challenge, has surfaced these 'ghosts' in major repositories like vLLM and TensorRT-LLM. The tool identifies files that have been deleted from git history but are still referenced by import statements, CI configurations, or documentation in the current working tree.

The vLLM Ghost That Haunts Main

The most striking finding comes from vLLM, where a file named placeholder_attn.py was deleted on September 24, 2025, in commit 969b4da3a6. Despite this removal, the file tests/plugins/vllm_add_dummy_platform/vllm_add_dummy_platform/dummy_attention_backend.py still contains the line from vllm.attention.backends.placeholder_attn import PlaceholderAttentionBackend. This broken import has persisted on the upstream main branch at commit 900b8b08e2 for thirteen months. While the plugin is pip-installed in CI jobs, the specific code path may not be triggered, or the job may not gate effectively, allowing the error to survive multiple commits.

Filtering False Positives in TensorRT-LLM and Triton

The developer behind 'ouija' spent significant effort eliminating false positives that initially plagued the tool. For instance, an early version flagged 234 'ghosts' in TensorRT-LLM, but 232 of these came from bulk configuration files like legacy-files.txt and pyproject.toml that simply list paths to ignore. After refining the logic to exclude bulk lists and changelogs, the tool reported 31 proven ghosts for TensorRT-LLM. Similarly, in Triton, a pre-commit hook still references a deleted workflow file .github/workflows/integration-tests.yml. This hook survives because its file pattern never matches, so it silently fails to run, masking the underlying deletion.

Local-First Architecture with Temporal Workflows

Unlike cloud-based code analysis tools, 'ouija' runs entirely locally using Python 3.9+ and git, with no external API dependencies for the detection phase. This ensures that private monorepos and unshipped client work remain on the developer's machine. For the 'altar' visualization, the tool uses gemma3:4b via Ollama to generate epitaphs for dead files, but the core detection logic is pure Python and git. To handle the computational load of scanning large repositories like ray (which has 7,500 deleted files), the project utilizes Temporal workflows. This ensures durability: if a worker process is killed mid-scan, a new worker can replay the history and resume exactly where the previous one left off, preventing redundant work.

Key Takeaways

  • 'ouija' detected 69 proven ghosts and 34 suspected ones across 29 distinct projects, including vLLM, PyTorch, and llama.cpp.
  • The tool distinguishes between 'proven' ghosts (full import paths) and 'suspected' ones (bare filenames) to maintain accuracy.
  • False positives from file renames, package conversions, and changelogs were systematically eliminated through rigorous testing.
  • The project demonstrates the value of local-first tools for analyzing sensitive private codebases without sending data to third-party APIs.

The Bottom Line

Static analysis tools are good at finding syntax errors, but they are terrible at finding social debt and forgotten connections. 'ouija' proves that a simple, local-first script can uncover critical rot in billion-dollar codebases where complex cloud scanners fail. If you are not auditing your deletion history, you are shipping ghosts.