codex - 💡(How to fix) Fix Make issue deduplicator suggestions surface-aware and confidence-explained

What variant of Codex are you using?

Repository maintenance / GitHub issue triage workflow

What feature would you like to see?

The Issue Deduplicator workflow currently comments with only a flat list of possible duplicates. It would be helpful if those suggestions were more surface-aware and included a short, user-visible reason or confidence signal for each match.

A narrow MVP could:

• include the current issue's product surface/variant and labels in the final comparison and/or output contract;
• ask the deduplication prompt to avoid suggesting candidates from a different Codex surface unless the underlying failure mode clearly crosses surfaces;
• return per-candidate rationale such as same surface + same symptom, different surface but same shared backend, or weak similarity;
• include the workflow's short reason in the posted comment, so reporters can tell why an issue was suggested instead of having to inspect every candidate manually;
• optionally suppress or down-rank candidates when the best match differs only by broad terms like performance, compaction, session, or remote without matching concrete reproduction details.

Additional information

I looked for an existing issue specifically about false/noisy duplicate suggestions and did not find one. Related historical work exists, but it appears to be about workflow reliability rather than the quality and transparency of the matches:

• #4628 added the issue deduplicator workflow.
• #11769 improved reliability with a two-pass strategy and richer issue input fields.
• #13203 and #4657 were workflow failure/bug reports.

Current workflow behavior, from .github/workflows/issue-deduplicator.yml, already collects issue labels and timestamps, asks Codex to identify up to five duplicates, and records a short reason, but the final public comment only says:

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

- #...

Recent examples show why a little more surface/context awareness would reduce reporter friction:

• #24764 was an App request, but the suggested duplicate was #23378 for the VS Code extension. The reporter replied that it was not a duplicate because the surface differs.
• #24668 reported TUI freezing when launching 15 subagents. Suggested issues included a memory leak, general performance, and reconnect loop; the reporter replied that the issue was specifically subagent performance, not those broader problems.
• #24761 was about preflighting/suppressing a known-denied Computer Use self-inspection path. The suggested duplicate #23452 covered the underlying safety refusal, while the new issue was about downstream UX/preflight behavior.
• #24780 is probably related to the mobile remote thread-list family, but the reporter had to manually explain the custom-provider contrast after multiple broad mobile-remote candidates were suggested.

This is not a request to remove deduplication. The deduplicator is useful, and broad related-issue hints can still help maintainers. The pain point is that the current comment format gives reporters no clue whether a candidate is a strong duplicate, a related shared subsystem, or a weak lexical match.

Potential validation:

1. Keep a small fixture set with current issue + candidate issues where product surface matters (app, extension, CLI, iOS, remote, custom-model, etc.).
2. Assert that exact-surface/exact-symptom duplicates still appear.
3. Assert that cross-surface suggestions require an explicit shared-backend/shared-contract rationale.
4. Assert that the final comment includes the short reason or per-candidate rationale without becoming noisy.

Out of scope for the MVP:

• replacing the Codex Action-based workflow;
• building a full duplicate-classification service;
• auto-closing or auto-marking issues as duplicates;
• changing GitHub labels or issue templates.