Any Plans or Interest in File Relationship Analysis?
Resolved 💬 6 comments Opened Apr 25, 2025 by williamfzc Closed Sep 3, 2025
💡 Likely answer: A maintainer (tibo-openai, collaborator)
responded on this thread — see the highlighted reply below.
Hi, very cool project!
I noticed that the community is working on codex-rs, and currently codex doesn’t support file relationship analysis.
I’m curious about the team’s thoughts on this. As I understand it, the goal is to be language-agnostic, so perhaps LSP-based solutions are intentionally avoided.
I’m currently maintaining a Rust project called gossiphs, which efficiently analyzes file relationships using Git and Tree-sitter. It seems like it could be a good fit for integration with codex-rs.
6 Comments
Hey @williamfzc , could you paint a few end-to-end scenarios to depict how this would be used from the perspective of a user?
We’ve been thinking about how file relationships might help in a few workflows. Two potential areas:
When reviewing a merge request, diffs often don’t show the full impact. By analyzing file relationships, we can surface related files (e.g. upstream/downstream dependencies) that may be indirectly affected.
This allows CI to perform context-aware checks—like flagging when a handler changes but its route or test isn’t updated.
👉 e.g. Analyzing the impact of changes in PR #647 beyond the directly modified files.
Some files are hard to understand in isolation. With relationship data, we can infer a file’s role—whether it’s core logic, infrastructure, or glue code—based on what it depends on and what depends on it.
This helps both humans and tools quickly grasp a file’s purpose without needing to read the entire codebase.
👉 e.g. Understanding what app.js actually does, based on its relations with other files.
are these issues somewhat related?
https://github.com/openai/codex/issues/192
Yes there are some similarities.
From the README, it looks like Codex has fairly clear use cases. It seems to only need to integrate a few essential tools to help it complete its tasks, which also makes its workflow more stable and predictable.
I can also share an experimental branch if it’s helpful to illustrate the idea.
That said, I’m not sure if codex would want to integrate this kind of third-party functionality.
yes, I expect forks to be more common once the codebase stabilizes a bit :)
Closing this as out of date, please re-file an issue if still relevant, thanks!