Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

GitHub issue-comment metadata causes false PR-target ambiguity in automatic approval

Open Beginner friendly
  • Is something wrong?
#54,821 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
json, rust
Domain
developer-experience, security

Research direction

Read codex-rs/core/assets/consequential_tool_message_templates.json and compare the add_comment_to_issue entry with the exposed tool contract. Update the target label and approval question to refer to an issue or pull request while preserving the pr_number field, then verify both target types through the production connector and inspect the returned canonical URLs. The public template change alone does not prove the automatic approval decision is fixed.

Written by the indexing model from the issue text.

Description

bug tool-calls

Summary
The managed GitHub tool github_add_comment_to_issue advertises a PR-only target, although its name, body description and observed behavior include ordinary issues. Automatic approval can therefore approve one ordinary-issue comment and reject a later comment to the same verified issue as an unauthorized target ambiguity.

This report is sanitized. Repository names, issuer names, private report content, account identifiers, credentials and complete conversation logs are excluded.

Exposed tool metadata
Description: "Create a top-level PR Conversation comment (Issue comment)."
Parameters:

  • repo_full_name: string
  • pr_number: number; description "Pull request number in the repository."
  • comment: string; description "Top-level comment body to add to the issue thread."

Reproduction from October 17, 2026 UTC

  1. Fetch an ordinary issue from a private repository; confirm the issue number and canonical /issues/ URL.
  2. Add a claim comment with github_add_comment_to_issue using that repository and number in pr_number. It succeeds.
  3. Later submit a handoff comment through the same tool to the same ordinary issue.
  4. Automatic approval rejects the request with this rationale, identifiers sanitized:
    "This externally visible comment is intended for issue #17, but the tool argument is explicitly pr_number: 17 and the target type is ambiguous, creating a material risk of posting to the wrong PR or failing; the user has not authorized that exact target ambiguity."

Expected behavior
The tool contract and approval presentation should state that the target can be either an issue or a pull request. Once the repository and numbered issue are verified, the misleading legacy argument name should not create a second, fictitious target.

Primary evidence
GitHub documents that issue comments and PR conversation comments share the Issues endpoints:
https://docs.github.com/en/rest/issues/comments#create-an-issue-comment

OpenAI Codex source at ce0323f2f2d3b25e82806cd555237da3db4e1897 also labels this managed GitHub tool's target "Pull request" and asks to comment "on a pull request":
https://github.com/openai/codex/blob/ce0323f2f2d3b25e82806cd555237da3db4e1897/codex-rs/core/assets/consequential_tool_message_templates.json
Relevant entry: tool_title add_comment_to_issue; connector_id connector_76869538009648d5b282a4bb21c3d157; source_tool_index 0.

Smallest correction

  1. Managed connector description: "Create a top-level conversation comment on a GitHub issue or pull request."
  2. Keep the existing pr_number wire field for compatibility; describe it as the issue or pull-request number, documenting its legacy name.
  3. Update the bundled approval label and question to "Issue or pull request" / "an issue or pull request".
  4. Verify ordinary-issue and PR conversation comments through the same production connector, checking the returned canonical target URL. Preserve normal approval checks.

The accompanying patch changes only the public Codex approval presentation. It does not modify the managed connector schema, and applying it alone must not be claimed to resolve automatic-review decisions.

Separate incident
A branch-create attempt returned "Automatic approval review failed: authorization changed before approval could be applied". Public Codex source maps that message to StaleAuthorization when authorization or review-context revisions change during review. The branch and PR subsequently succeeded. This is distinct from the comment metadata problem; the original internal attempt count and precise changing evidence were not retained, so no specific race is claimed proven.

Source:
https://github.com/openai/codex/blob/ce0323f2f2d3b25e82806cd555237da3db4e1897/codex-rs/core/src/guardian/review_request.rs
https://github.com/openai/codex/blob/ce0323f2f2d3b25e82806cd555237da3db4e1897/codex-rs/ext/guardian-reviewer/src/retry.rs

Public Codex approval-template patch

diff --git a/codex-rs/core/assets/consequential_tool_message_templates.json b/codex-rs/core/assets/consequential_tool_message_templates.json
--- a/codex-rs/core/assets/consequential_tool_message_templates.json
+++ b/codex-rs/core/assets/consequential_tool_message_templates.json
@@ -9,7 +9,7 @@
       "template_params": [
         {
           "name": "pr_number",
-          "label": "Pull request"
+          "label": "Issue or pull request"
         },
         {
           "name": "repo_full_name",
@@ -20,7 +20,7 @@
           "label": "Comment"
         }
       ],
-      "template": "Allow {connector_name} to add a comment to a pull request?"
+      "template": "Allow {connector_name} to add a comment to an issue or pull request?"
     },
     {
       "source_tool_index": 1,
Dominant language
Rust
Stars
129k
Forks
20.3k
Avg merge
1m
Merged PRs (30d)
998

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.