Feature request: give Codex IDE-like semantic code navigation

Description

Codex frequently needs to explore unfamiliar codebases before making changes. Today that usually means repeatedly using rg, reading whole files, or opening arbitrary file chunks. This works, but it is context-heavy and often inefficient: large files include imports, comments, neighboring functions, tests, generated code, and other content that may be irrelevant to the actual question.

It would be valuable for Codex to have first-class, symbol-aware code navigation tools, closer to what developers get from IDEs and language servers.

Proposed feature

Add built-in codebase exploration tools that let Codex inspect code semantically rather than only as raw text.

Useful capabilities could include:

• Search symbols by name, kind, language, and path.
• Open the exact body of a function, class, method, type, enum, or module.
• Show a compact outline of a file without reading the whole file.
• Find definitions and references.
• Show imports, exports, callers, callees, inheritance, and dependency edges where available.
• Expand context around a symbol intentionally, instead of by arbitrary line ranges.
• Cache or index repository structure locally so repeated exploration gets cheaper over time.
• Fall back to rg/plain text search for unsupported languages or ambiguous cases.

Why this matters

Code exploration is one of Codex's most common workflows. Before editing, reviewing, debugging, or explaining code, Codex usually needs to understand where relevant behavior lives and how pieces connect.

A semantic navigation layer would likely improve:

• Token efficiency, by avoiding unnecessary whole-file reads.
• Speed, by reducing repeated search/read cycles.
• Accuracy, by making it easier to inspect the right definitions and references.
• Large-repo behavior, especially in monorepos or files with many unrelated symbols.
• User trust, because Codex could cite the exact symbols it inspected rather than broad file chunks.

Suggested direction

This does not need to replace rg. A good model would be:

1. Use symbol-aware navigation when available.
2. Use concise AST/LSP/tree-sitter-style outlines for orientation.
3. Expand only the specific symbols needed for the task.
4. Fall back to rg and raw file reads when semantic data is unavailable.

This would give Codex an IDE-like code navigation substrate while preserving the current flexible shell-based workflow.

Example

I built codescope for my own use. I am linking it here as a demonstration/example of the expected capabilities:

codescope list-functions --path .
codescope extract-function --name Namespace::Class::method --path src
codescope extract-symbol --name Foo --kind class --path .
codescope extract-variable --name CONFIG --scope Foo --path .
codescope references --name foo --path .
codescope callers --name foo --path .
codescope context --name foo --path .

It provides a more structured way for an agent to inspect code symbols before opening large source files, reducing the need to repeatedly rg through a repo and read broad file chunks. A Codex-native version would not need to match that implementation exactly, but the core idea is useful: expose compact, semantic code navigation primitives that help the agent decide what code to inspect next.