Explicit official docs URLs should bypass search_openai_docs
What version of Codex CLI is running?
0.116.0
What subscription do you have?
Plus
Which model were you using?
gpt-5.4, reasoning: high
What platform is your computer?
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64
What terminal emulator and version are you using (if applicable)?
VS Code integrated terminal in WSL2; shell: bash
What issue are you seeing?
When task context already provides exact official docs URLs, Codex still calls search_openai_docs first instead of fetching those URLs directly. This lets a generic search -> fetch heuristic override more specific instructions already present in context.
In the reproduced case, the working context explicitly provided exact developers.openai.com Codex docs URLs from local repo guidance, but Codex still called search_openai_docs(..., limit=5) to rediscover those same pages before attempting to fetch them.
What steps can reproduce the bug?
- Start a Codex CLI session in a repo whose instructions explicitly tell the agent to consult specific official docs URLs.
- Ask Codex a prompt/workflow-design question that causes it to load those docs.
- Observe tool usage.
- Codex uses
search_openai_docsfirst instead of fetching the exact known URLs directly.
What is the expected behavior?
If the task context already identifies the exact official docs URLs to use, Codex should fetch those URLs directly. Docs search should be reserved for cases where the correct page is unknown, inaccessible, or needs discovery.
Additional information
- I searched for obvious duplicates in
openai/codexbefore filing and did not find one with the keywords I tried. - A likely contributor is generic docs-tool guidance that says to prefer search before fetch. That heuristic makes sense when the target page is unknown, but it should not override exact source instructions already present in context.
- This report is about instruction/tool-precedence behavior, not the correctness of the docs contents themselves.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗