Bug: Quota exhausted reading in symbols from DerivedData

Resolved 💬 3 comments Opened Apr 18, 2025 by guidedways Closed Aug 7, 2025
💡 Likely answer: A maintainer (guidedways, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.1.2504161551

Which model were you using?

o4-mini

What platform is your computer?

Darwin 24.4.0 arm64 ar

What steps can reproduce the bug?

We're working on an iOS / macOS mixed project (obj-c / swift). I had codex running at the root folder of the project (millions of lines of code, spread across directories). I gave a lengthy instruction with explicit file names to swift for and method names to study, however it was unable to look for the methods oddly (claude code is able to do this easily, for context) and then it started searching in the DerivedData folder (which is marked as a hidden folder within the same project folder: .DerivedData.noindex). It then wasted the entire context on this.

Codex understood it's looking under the wrong folder but even after _adjustments_ it continued looking under DerivedData till it suddenly quit with a rate_limit error:

Searching for alarm templates

    I’m not finding any matches, which makes me wonder if it’s actually supposed to be spelled as '-defaultAlarmTemplatesForEventType:' without a prefix. Since
    grep found nothing, it suggests this code might not be in the current repository. It’s possible that it resides in macOS-calendaring frameworks or maybe it’s
    hidden in Objective-C files. To dig deeper, I’m going to search for "AlarmTemplates" next.

    thinking for 54s

    thinking for 54s

    command

    $ grep -R AlarmTemplate -n .

    command.stdout (code: 143, duration: 10s)

    Binary file ./calendar/.DerivedData.noindex/BusyCal/Index.noindex/DataStore/v5/records/PC/CalendarWC+Menu_Edit.m-X7CO5DPE91PC matches
    Binary file ./calendar/.DerivedData.noindex/BusyCal/Index.noindex/DataStore/v5/records/YQ/PrefsController+TimedEventAlarms.m-3IJEW4UF6NXYQ matches
    Binary file ./calendar/.DerivedData.noindex/BusyCal/Index.noindex/DataStore/v5/records/SJ/BirthdaySyncTask.m-25TBHWRI9IMSJ matches
    Binary file ./calendar/.DerivedData.noindex/BusyCal/Index.noindex/DataStore/v5/records/9X/PrefsController.h-LIMW3D9IY89X matches
    ... (342 more lines)

    thinking for 74s

    Refining search paths

    I noticed that the grep command returned excessive output, with many automatically generated Swift headers from the DerivedData directory. That's definitely
    not useful! I need to focus on source code definitions in Swift or Objective-C files instead. Since this project is an Xcode project, I'll refocus my search
    specifically inside the calendar/ directory and ignore DerivedData altogether. It seems I need to adjust my grep command to skip the DerivedData directory for
    a cleaner search.

    thinking for 74s

    thinking for 74s

    thinking for 74s

What is the expected behavior?

Look for the correct code, ignore hidden folders with a .

What do you see instead?

Searching the wrong folders, unable to find correctly specified method name (its prefix) in a obj-c .m file in one of the sub-folders.

Additional information

_No response_

View original on GitHub ↗

3 Comments

kbigelo · 1 year ago

Yes, grep is a problem here. o3 burned 22M tokens in a few sessions with grep. Then my T705 SSD started making the noise of a full disk search. This needs urgent attention.

!Image

guidedways contributor · 1 year ago

Wow. 22 million tokens in a day! Thankfully for me codex either crashed or quit unexpectedly automatically after throwing a rate_limit error. I'd hate to be billed $118 for a prompt that did nothing. I was tempted to try o3 first but was worried it may get out of hand, so this was my 'test the waters' and it failed immediately on an initial prompt.

codex-maintainers · 1 year ago

Thank you for the feedback! Please try again on the latest version of Codex CLI. If the issue persists, we're happy to take a look.