BUG: Make repository indexing read-only (avoid dependency installs during static analysis)

[tanii1125]

Is there an existing issue for this?

• I have searched the existing issues

What happened?

📌 Issue Overview

While working with the repository indexer, I noticed that indexing a codebase can unintentionally install dependencies and mutate the cloned repository’s environment. This makes indexing non-deterministic and breaks the expectation that indexing is a read-only operation.

🔍 Steps to Reproduce

1. Go to the Discord server
2. Run /index_repository AOSSIE-Org/Devr.AI
3. Observe the indexing process in the Falkor backend logs

🎯 Expected Behavior

1. Indexing is deterministic and read-only
2. No virtual environments or package installs are triggered
3. Static indexing works without dependency metadata
4. Dependency analysis can be explicitly enabled later if needed

🚨 Actual Behavior

When indexing a Python repository:

1. venv/ directories can be created inside the cloned repo
2. Dependencies like tree-sitter, multilspy, and sentence-transformers may get installed
3. Indexing can remain stuck in a pending state
4. Additionally, attempting to delete a failed index returns an error (“Failed to delete graph from backend”), leaving the system in a stuck state.

This behavior occurs even when:

1. LSP is disabled
2. Poetry is disabled
3. The intent is static (AST-only) analysis

📷 Screenshot

On Discord:

Terminal

backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/types/role.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/types/snowflake.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/types/sticker.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/types/team.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/types/template.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/types/widget.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/ui/__init__.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/ui/button.py over existing file
Installing /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/venv/lib/python3.10/site-packages/discord/ui/item.py over existing file
.
.
ERROR:code_graph:Error adding dependencies: 'NoneType' object is not iterable
INFO:root:Processing file (1/168): /home/tanisha/Devr.AI/backend/app/database/falkor/code-graph-backend/api/repositories/Devr.AI/backend/routes.py
INFO:werkzeug:127.0.0.1 - - [14/Jan/2026 01:10:27] "POST /analyze_repo HTTP/1.1" 500 -

Evidence (Indexing Mutates Environment)

1. A venv/ directory is created inside the cloned repository
2. Python dependencies are installed into that environment
3. Existing files under site-packages/ are overwritten
4. Indexing eventually fails with a dependency-related error

💡 Suggested Improvements

1. Disables dependency resolution by default during indexing
2. Introduces a static_only mode for analyzers
3. Separates code graph (AST) generation from dependency graph resolution
4. Ensures indexing never installs packages or modifies the filesystem

Record

• I agree to follow this project's Code of Conduct
• I want to work on this issue

[AkshitGarg054]

Hey @tanii1125 , Thanks for raising this issue. Your observations around dependency installation and repository mutation during indexing make a lot of sense.

Regarding the point that indexing can remain stuck in a pending state : I recently raised a related issue and opened a PR that addresses this issue. After discussing with the project mentor, the flow was updated so that repositories in pending or failed state can always be safely re-indexed via /index_repository, which prevents permanent stuck states even if the code-graph backend crashes mid-analysis.
I would recommend you to take a look at that PR first, since it already handles recovery from failures and may reduce the impact of some of the failure modes described here.

On the point about deletion failing after a failed indexing (“Failed to delete graph from backend”) : my current understanding is that, when indexing fails, the user gets a message displayed about it and can always restart indexing via /index_repository, which resets the state and triggers a fresh indexing. So the system should not remain permanently stuck from a user’s perspective. However, I may be missing a specific edge case here. Please correct me if I am wrong somewhere.

[tanii1125]

@AkshitGarg054 Thanks for looking into this. I’ve gone through your PR and it does address the repository getting stuck in the pending state, which is helpful.

However, the issue I’m raising here is a bit different, it’s specifically about repository mutation during indexing, where dependencies are downloaded and environments (like venvs) are created as part of the indexing process. This makes indexing non–read-only and non-deterministic, which is the main concern in this issue.