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:
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:
gh issue create \
--repo pingdotgg/t3code \
--title "..." \
--body-file report.md \
--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:
GraphQL: areidyOTH does not have the correct permissions to execute
AddLabelsToLabelable (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
-
Use a GitHub account that can create issues in pingdotgg/t3code but does not have
repository triage or write permission.
-
Start npx t3 triage.
-
Investigate a defect and approve the final issue text.
-
Have the agent create the issue with gh issue create --label via-triage.
-
Inspect the resulting issue.
-
Attempt to add the label explicitly with:
gh issue edit <number> \
--repo pingdotgg/t3code \
--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
# Issue creation returned a URL and no label error:
https://github.com/pingdotgg/t3code/issues/8059
# Remote verification:
labels: []
# Explicit correction:
gh issue edit 8059 --repo pingdotgg/t3code --add-label via-triage
# Result:
GraphQL: areidyOTH does not have the correct permissions to execute
AddLabelsToLabelable (addLabelsToLabelable)
Related issues
Suggested fixes
Any of the following would make the workflow reliable:
- Submit through the
via-triage.yml issue form so GitHub applies its configured label.
- Provide a repository-owned workflow or bot that applies
via-triage to submissions
produced by the triage flow.
- Detect whether the authenticated account can assign labels before posting.
- Verify the created issue’s labels and clearly report when maintainer action is
required.
- 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
What happened
A
t3 triagesession successfully created issue #8059 as an ordinary externalcontributor, but the issue was left without the required
via-triagelabel.The triage playbook tells the agent both to follow the
via-triageissue template andto 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:
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:gh issue create \ --repo pingdotgg/t3code \ --title "..." \ --body-file report.md \ --label via-triageThat does not use GitHub’s issue-form submission path. Assigning
--labelthereforeuses the reporter’s own repository permissions.
In this occurrence,
gh issue createreturned success and created #8059, but the issuehad no labels. It did not surface the rejected label assignment. A subsequent explicit
attempt exposed the actual permissions failure:
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/newURL—also doesnot explicitly require selecting
via-triage.yml, so that path may bypass thetemplate’s automatic label as well.
Steps to reproduce
Use a GitHub account that can create issues in
pingdotgg/t3codebut does not haverepository triage or write permission.
Start
npx t3 triage.Investigate a defect and approve the final issue text.
Have the agent create the issue with
gh issue create --label via-triage.Inspect the resulting issue.
Attempt to add the label explicitly with:
The issue is created without the label, and the explicit attempt fails with
AddLabelsToLabelable.Version
0.0.34-nightly.20260824.1172Exact release source:
b4be33f0747445f1c9df126e932c7b9792f322d5The same playbook instructions are present on current
mainas of 2026-08-24.Environment
Evidence
Related issues
Suggested fixes
Any of the following would make the workflow reliable:
via-triage.ymlissue form so GitHub applies its configured label.via-triageto submissionsproduced by the triage flow.
required.
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.ymlform should allow GitHub to apply the configured labelautomatically.
Filed by
Codex (GPT-5) via
t3 triage