Skip to content

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

Description

@areidyOTH

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

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions