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

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:

labels:
  - 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:

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

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:

   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

• #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

Start with the t3 triage entry point and its playbook instructions around gh issue create and the fallback /issues/new URL. Inspect the via-triage.yml issue form to understand its automatic label behavior. Done means external-contributor reports reliably receive via-triage or clearly surface that maintainer action is required, without silently treating label failure as success.