Sign up
View stargazersSign up

t3 triage cannot apply the via-triage label for external contributors#8061

openedAug 24, 2026byAareidyOTH

What happened

A t3 triage session successfully created issue #8059 as an ordinary external contributor, but the issue was left without the required via-triage label.

The triage playbook tells the agent both to follow the via-triage issue template and to apply that label. However, its direct GitHub CLI/API path requires the reporter to have repository triage or write permission.

The authenticated reporter could create issues and comments but could not assign labels.

Diagnosis

The repository’s issue form correctly declares:

yaml
1labels:
2 - via-triage

GitHub automatically applies template-declared labels when an issue is submitted through that issue form.

The triage playbook instead permits an authenticated agent to create the issue directly with gh. A typical command is:

shell
1gh issue create \
2 --repo pingdotgg/t3code \
3 --title "..." \
4 --body-file report.md \
5 --label via-triage

That does not use GitHub’s issue-form submission path. Assigning --label therefore uses the reporter’s own repository permissions.

In this occurrence, gh issue create returned success and created #8059, but the issue had no labels. It did not surface the rejected label assignment. A subsequent explicit attempt exposed the actual permissions failure:

text
1GraphQL: areidyOTH does not have the correct permissions to execute
2AddLabelsToLabelable (addLabelsToLabelable)

This is expected GitHub permission behavior, but an unhandled case in the T3 Code triage workflow. Most external bug reporters will not have permission to label issues.

The fallback described by the playbook—building a prefilled /issues/new URL—also does not explicitly require selecting via-triage.yml, so that path may bypass the template’s automatic label as well.

Steps to reproduce

  1. Use a GitHub account that can create issues in pingdotgg/t3code but does not have repository triage or write permission.

  2. Start npx t3 triage.

  3. Investigate a defect and approve the final issue text.

  4. Have the agent create the issue with gh issue create --label via-triage.

  5. Inspect the resulting issue.

  6. Attempt to add the label explicitly with:

    shell
    1gh issue edit <number> \
    2 --repo pingdotgg/t3code \
    3 --add-label via-triage

The issue is created without the label, and the explicit attempt fails with AddLabelsToLabelable.

Version

0.0.34-nightly.20260824.1172

Exact release source: b4be33f0747445f1c9df126e932c7b9792f322d5

The same playbook instructions are present on current main as of 2026-08-24.

Environment

  • T3 Code on Linux x64
  • GitHub CLI 2.46.0
  • Authenticated external contributor without repository label permissions

Evidence

shell
1# Issue creation returned a URL and no label error:
2https://github.com/pingdotgg/t3code/issues/8059
3
4# Remote verification:
5labels: []
6
7# Explicit correction:
8gh issue edit 8059 --repo pingdotgg/t3code --add-label via-triage
9
10# Result:
11GraphQL: areidyOTH does not have the correct permissions to execute
12AddLabelsToLabelable (addLabelsToLabelable)

Related issues

  • #8059 is the issue created by the affected triage session. It remains unlabelled.
  • No existing issue covering this label-permission gap was found.

Suggested fixes

Any of the following would make the workflow reliable:

  1. Submit through the via-triage.yml issue form so GitHub applies its configured label.
  2. Provide a repository-owned workflow or bot that applies via-triage to submissions produced by the triage flow.
  3. Detect whether the authenticated account can assign labels before posting.
  4. Verify the created issue’s labels and clearly report when maintainer action is required.
  5. Ensure label failure cannot be silently hidden behind otherwise successful issue creation.

Fix applied or workaround

No label could be applied with the reporter’s permissions.

A maintainer can label #8059 manually. For future reports, submitting through the repository’s via-triage.yml form should allow GitHub to apply the configured label automatically.

Filed by

Codex (GPT-5) via t3 triage

Ppnupu5d ago
Synced from GitHub

This is still happening. Here are two data points, and a tested way to keep the label without a browser. Open fix PR: #24955.

How often the label is missing. On 2026-10-26 I searched the bodies of issues created since 2026-10-01 for (via|with|from|using) (npx )?t3 triage, excluding "not via" statements. This heuristic matched 141 issues, including three false positives. 68 of them currently have via-triage. Recent examples: #25488, #25419, #25307, #25161, #24998. Some of the labelled ones got the label afterwards from a maintainer (for example #22626 and #22620), so a label being there now doesn't necessarily mean it was applied at filing. In the latest 600 issues alone (back to about Oct 20), 4 of 45 have it.

A way to keep the label without opening a browser. #24955 checks the reporter's triage permission and, without it, sends them to the via-triage.yml web form. GraphQL createIssue takes issueTemplate, which GitHub documents as applying the named template's labels and assignees. In cli/cli#13589 a read-only user reports that this applied a .yml form's labels. So the agent could file directly:

sh
1gh api graphql \
2 -f query='mutation($repo:ID!,$title:String!,$body:String!){createIssue(input:{repositoryId:$repo,title:$title,body:$body,issueTemplate:"Triage report"}){issue{url}}}' \
3 -f repo="$(gh api repos/pingdotgg/t3code --jq .node_id)" \
4 -f title="..." -F body=@issue.md

I tested this on my fork (pnupu/t3code, same via-triage.yml) using a second account that has only read access there (permissions.triage: false):

TestResult
Read-only: GraphQL createIssue with issueTemplate: "Triage report"Created, with via-triage applied (the timeline shows the label added by the reporter's account)
Read-only: gh issue create --label via-triage (the current playbook path)Created and exited 0, but with no labels: the silent drop this issue describes
issueTemplate with a wrong template name (tested as owner)NOT_FOUND, exit 1, nothing created

This suggests reporters signed in to gh could file directly, without a separate triage-permission check. I tested this on the fork, not upstream. The web form could stay as a fallback.

Researched with Claude Code (Claude Opus 5.5), with numbers and claims checked by Codex (gpt-6.1-sol).