github_issue_write silently drops labels when caller lacks AddLabelsToLabelable permission #3160

Describe the bug

github_issue_write with method: "create" (and method: "update") silently drops the labels argument when the calling user lacks AddLabelsToLabelable permission on the target repository. The API returns success (issue created/updated, no error), but no label is applied. The failure is only detectable by reading back the issue's labels.

Observed against an upstream repo where the caller is not a maintainer, using a label that verifiably exists in the repository (enhancement, applied via the repo's issue template):

1. github_issue_write create with labels: ["enhancement"] → returns success + issue URL.
2. github_issue_read with get_labels on the created issue → [] (empty).
3. Retried via github_issue_write update with labels: ["enhancement"] → again success, still empty.
4. The label exists in the repo: GitHub_get_label returns the label (color a2eeef, description "New feature or request").
5. The equivalent CLI operation fails loudly: gh issue edit <n> --add-label enhancement exits 1 with a GraphQL permission error (see Logs).

So the MCP tool succeeds silently where the CLI surfaces the permission boundary — the labels field is dropped without any error or warning.

Affected version

Could not capture the server version: the docker daemon is not running in this environment (docker run -i --rm ghcr.io/github/github-mcp-server ./github-mcp-server --version failed with failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory).

Environment used: the hosted GitHub MCP endpoint at https://api.githubcopilot.com/mcp/ (as configured by the host client).

Steps to reproduce the behavior

1. Authenticate to the MCP server as a user without AddLabelsToLabelable permission on an upstream repo (i.e. not a maintainer/collaborator).
2. Confirm a label exists in that repo (e.g. via get_label for the label the repo's issue template applies, such as enhancement).
3. Call github_issue_write with method: "create", owner, repo, title, body, and labels: ["enhancement"].
4. View the output — the tool reports success and returns the new issue URL.
5. Call github_issue_read with method: "get_labels" for that issue — the labels list is empty.
6. Repeat with method: "update" adding the same label — same silent drop.

Expected vs actual behavior

• Expected: either the label is applied, or the tool returns an error indicating the label(s) could not be applied (matching the CLI's behavior).
• Actual: the tool returns success with no error, and the label is silently not applied. The caller has no way to know the label was dropped without a read-back.

Logs

gh issue edit confirmation of the permission boundary (CLI fails loudly where the MCP tool succeeds silently):

gh issue edit 44 --add-label enhancement
GraphQL: HaleTom does not have the correct permissions to execute `AddLabelsToLabelable` (addLabelsToLabelable)

get_labels read-back on the issue created by the MCP tool with labels: ["enhancement"]: [].