codex - 💡(How to fix) Fix Mac app: persistent project index UI to reduce repeated Exploring time [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20454Fetched 2026-05-01 05:42:57
View on GitHub
Comments
3
Participants
3
Timeline
6
Reactions
0
Timeline (top)
commented ×3labeled ×2closed ×1

Root Cause

By comparison, Cursor has a visible Codebase Indexing feature for a workspace. In practice, that kind of persistent project index makes locating relevant files and code areas feel much more efficient, because the tool does not have to rely only on repeated ad-hoc file exploration every time the user asks a project-level question.

RAW_BUFFERClick to expand / collapse

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 provide a first-class, visible project index and exploration cache experience that reduces repeated long Exploring phases in large repositories.

This request is specifically about the desktop app user experience and project workflow, not only a CLI command or a standalone terminal search feature.

Current problem

In the Mac app, many tasks spend a large amount of time repeatedly reading files before the actual implementation or debugging work begins. This is especially noticeable in larger repositories or when running several related tasks in the same project.

Even when the user has already worked with the same repository many times, the app can still feel like it is starting project discovery from scratch. That makes the desktop workflow slower than it needs to be.

By comparison, Cursor has a visible Codebase Indexing feature for a workspace. In practice, that kind of persistent project index makes locating relevant files and code areas feel much more efficient, because the tool does not have to rely only on repeated ad-hoc file exploration every time the user asks a project-level question.

I would like the Codex Mac app to offer a similar first-class project indexing experience, adapted to Codex's own agent workflow.

Requested Mac app behavior

Please consider adding a project-level index and project-discovery UI to the Mac desktop app, with controls such as:

  • visible indexing / syncing status for each selected project or worktree
  • pause, resume, delete, and rebuild index controls
  • incremental updates when files change
  • clear support for an ignore file such as .codexignore, in addition to .gitignore
  • a way to exclude build outputs, generated files, logs, vendor folders, secrets, large binaries, and other irrelevant files
  • clear privacy documentation explaining what is stored locally and whether embeddings or metadata leave the machine
  • use of the index to reduce repeated file-reading during Exploring
  • final verification by reading current source files before editing, so the index is used for retrieval and prioritization rather than blindly trusted

Why this matters

This would improve the Mac desktop app experience in several ways:

  • Faster startup for coding tasks in medium and large repositories.
  • Less repeated repository exploration across related tasks and sessions.
  • Less time spent waiting before Codex starts the actual work.
  • Less context and usage spent on rediscovering project structure.
  • Less need for users to manually list every relevant directory or file in prompts.
  • Better file retrieval efficiency, closer to the experience users get from tools that already maintain a workspace index.
  • Better alignment with desktop-app expectations, where a selected project feels persistent and reusable instead of freshly rediscovered every time.

Additional information

The important part of this request is the Mac app product experience: a visible, user-controllable project indexing/exploration layer integrated into the desktop app. The index should help Codex find candidate files and areas faster, while actual edits should still be based on reading the current files.

extent analysis

TL;DR

Implement a visible project index and exploration cache in the Codex Mac desktop app to reduce repeated long Exploring phases in large repositories.

Guidance

  • Consider adding a project-level index and project-discovery UI to the Mac desktop app with controls such as visible indexing/syncing status, pause, resume, delete, and rebuild index controls.
  • Implement incremental updates when files change and support for an ignore file such as .codexignore to exclude irrelevant files.
  • Use the index to reduce repeated file-reading during Exploring and verify by reading current source files before editing.
  • Provide clear privacy documentation explaining what is stored locally and whether embeddings or metadata leave the machine.

Notes

The implementation details of the project index and exploration cache are not specified, and the exact technical requirements are unclear.

Recommendation

Apply workaround: Implement a project indexing feature in the Codex Mac desktop app to improve the user experience and reduce repeated repository exploration.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Mac app: persistent project index UI to reduce repeated Exploring time [3 comments, 3 participants]