codex - 💡(How to fix) Fix Feature request: Cursor-style codebase indexing for the Codex Mac app to reduce repeated Exploring time [1 comments, 2 participants]

What variant of Codex are you using?

Codex Mac desktop app

What feature would you like to see?

I would like the Codex Mac desktop app to add an optional, project-level codebase indexing feature similar in spirit to Cursor's Codebase Indexing.

The core idea is to let Codex build and maintain a reusable index for a selected workspace, then use that index when the agent needs to locate relevant files, symbols, or concepts. Ideally this would be integrated into the Mac app UI with a visible indexing status panel, pause/resume, delete/rebuild index, and clear ignore-file support.

Current pain point

When working in larger projects, Codex often spends a long time in Exploring, repeatedly reading files before it can start the actual implementation or debugging work.

This is understandable for correctness, but in practice it can become very slow. Many tasks require Codex to rediscover the same project structure, related source files, tests, and configuration over and over again. That creates several problems:

• A lot of time is spent on basic repository discovery before the real work begins.
• Codex may reread the same or similar files across different tasks or sessions.
• Larger codebases make the first few minutes of a task feel dominated by file exploration.
• Users have to spend more prompt text telling Codex exactly which areas of the repository to inspect.
• Repeated exploration can consume context and usage before any meaningful implementation work happens.
• Keyword search is not always enough when the relevant code uses different names than the user's natural-language description.

Suggested behavior

A good first-class experience for the Mac app could include:

1. Workspace-level background indexing

   • Build a reusable index for the currently selected project/worktree.
   • Update incrementally when files change instead of rebuilding everything.
   • Clearly show whether the index is ready, syncing, stale, paused, or deleted.

2. Agent-accessible semantic search

   • Let Codex use the index to quickly find likely relevant files and snippets before falling back to full exploration.
   • Support natural-language queries about where a feature, data flow, UI behavior, or bug-related logic is implemented.
   • Return file paths, symbols/snippets, and line ranges so Codex can still open and verify the real source before editing.

3. Local-first and privacy-aware controls

   • Make indexing opt-in or clearly configurable.
   • Provide a .codexignore / ignore-file mechanism in addition to .gitignore.
   • Allow users to exclude build outputs, logs, generated files, vendor folders, secrets, and large binary/data files.
   • Provide a simple "Delete Index" button.
   • Clearly document what is stored locally and whether any embeddings/metadata ever leave the machine.

4. Mac app UI integration

   • Add an "Indexing & Docs" or "Codebase Index" panel similar to Cursor's indexing UI.
   • Show recent indexed files, progress, errors, and ignored files.
   • Allow reindexing a project/worktree manually.

5. Fallback behavior

   • The index should not replace reading source files. It should help Codex find the right files faster, then Codex can still read and verify the relevant files before making changes.

Benefits

This would make Codex much more efficient for real-world projects:

• Faster task startup on medium/large repositories.
• Less repeated Exploring time across related tasks.
• Better file discovery when user wording does not match exact code identifiers.
• Lower context waste from repeated repo scanning.
• Less need for users to manually provide long lists of relevant files.
• More reliable multi-file changes because the agent can discover related files through semantic relationships, not only grep.
• Better experience for desktop-app users who expect a persistent project workspace, not a fresh repo investigation every time.

Related issues

This is related to existing requests for semantic search / persistent project context, but this request is specifically about the Codex Mac desktop app UX and reducing repeated Exploring latency:

• #5181
• #14682

Additional information

I do not want Codex to blindly trust an index. The index should be used as a retrieval layer for finding candidate files/snippets quickly, while final reasoning and edits should still be based on reading the actual current files.

The main request is: please add a first-class, visible, configurable codebase indexing feature to the Codex Mac app so large projects do not require slow repeated exploration for every task.