GitHub connector exposes create_pull_request but not create_issue

[fireshort]

Summary

The curated GitHub connector bundled with Codex exposes issue read/search/comment actions and pull request creation, but it does not expose a create_issue action.

Evidence

In the current GitHub connector tool list, I can see actions such as:

• github_fetch_issue
• github_fetch_issue_comments
• github_search_issues
• github_add_comment_to_issue
• github_create_pull_request

But there is no github_create_issue.

Actual behavior

When a user asks Codex to file a GitHub issue, the agent cannot do it through the GitHub connector and must fall back to browser automation or ask the user to file it manually.

Expected behavior

Please add a create_issue capability to the GitHub connector, similar to create_pull_request, or document clearly that issue creation is intentionally unsupported.

Why this matters

Creating issues is a common GitHub workflow. Supporting PR creation but not issue creation creates a noticeable gap in the connector's write capabilities.

[github-actions]

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

• GitHub connector should support issue creation or surface permission upgrade flow #17475

Powered by Codex Action

[raye-deng]

This is a good observation about the API surface gap. When an AI agent can read issues and create PRs but cannot create issues, it creates an awkward workflow where the agent has to ask the human to perform a manual step that is structurally identical to something it can already do programmatically.

More broadly, we see this pattern frequently with AI-generated API integrations: the generated code covers the happy path for the operations the developer thought of, but misses operations that exist in the same API namespace. The agent can fetch_issue, search_issues, and create_pull_request, but creating an issue — the most basic write operation — is absent.

This type of API surface gap is hard to catch in code review because the code that exists is correct. The problem is the code that is missing. SonarQube and traditional linters do not check "does this integration cover all available operations?" — they validate what is there, not what is absent.

We have found it useful to run an API coverage comparison that checks the operations an integration actually implements against the full API surface documented by the provider. It catches exactly this kind of gap — missing endpoints that belong to the same resource family.

npx @opencodereview/cli scan . --sla L1 includes API coverage analysis for common integrations.

[fireshort]

This appears to overlap heavily with #17475, which already covers missing GitHub issue creation support and the fallback/permission gap. Keeping #17475 as the canonical issue seems reasonable.