Codex chat search matches injected AGENTS.md instructions, polluting results and snippets
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What version of the Codex App are you using?
26.903.61454 (build 8378), read from the installed macOS application bundle. The application is currently packaged as ChatGPT.app; this report concerns its Codex chat search.
What subscription do you have?
ChatGPT account; subscription tier not verified for this report.
What platform is your computer?
macOS 26.6.2 (25G83).
What issue are you seeing?
Codex's cross-chat search matches automatically supplied AGENTS.md instructions and displays those instructions as result snippets. Repeated global guidance therefore causes unrelated chats to appear for the same query, making it difficult to locate conversations that actually discussed the topic.
In the observed case, I searched for 后续 (roughly “subsequent” / “going forward”). My global AGENTS.md contains a Markdown formatting rule with this example:
Keep surrounding punctuation outside `**...**`; write `**加粗内容**。后续中文内容` and avoid ...
The search screenshot shows at least four separate chat results displaying the same instruction fragment:
... g punctuation outside `**...**`; write `**加粗内容**。后续中文内容` and avoid ...
Those repeated instruction matches are mixed with results whose snippets contain ordinary conversation content. The shared setup text is competing with the content I intended to search.
The screenshot establishes that instruction text is used for matching/snippets. I have not inspected the indexing implementation or confirmed whether each affected chat also has a genuine conversation-body match. I am reporting noisy results and snippets, rather than claiming the search returns zero results.
What steps can reproduce the bug?
Observed workflow:
- Use a global AGENTS.md containing the formatting rule above across multiple Codex chats.
- Open the app's cross-chat search.
- Search for
后续. - Observe multiple results whose preview repeats the global formatting instruction instead of a topic-specific message.
Suggested minimal isolation test for maintainers (not separately executed here): place a unique marker such as agents-search-marker-7f93 only in global AGENTS.md, start several otherwise unrelated chats, and search for that marker. Check whether chats match solely because they received the injected instructions.
What is the expected behavior?
Default chat search should prioritize user-authored conversation messages, assistant responses, and chat titles. Automatically injected AGENTS.md guidance should be excluded from default matching and snippets, or made explicitly opt-in via an “Include injected context/instructions” filter.
If a chat has both an instruction match and a genuine conversation match, its preview should show the conversation match. Users should be able to distinguish these sources.
Additional information
The original screenshot contains private project and chat names, so its relevant text is transcribed above. This issue concerns Codex desktop cross-chat search and its treatment of injected instructions. No claim is made about the model's ability to follow AGENTS.md.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the Codex desktop cross-chat search entry point and trace how injected AGENTS.md guidance enters matching and snippet generation; the report names no implementation files or tests. Reproduce with the unique marker agents-search-marker-7f93 across several chats, then verify that default results and snippets exclude instruction-only matches while retaining genuine conversation matches.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- macos, rust
- Domain
- desktop-dev, search
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100