tea issues edit --add-labels and --remove-labels resolve label names against
the repository's own label set only. Every Kind/*, Priority/*, Reviewed/*
and Status/* label lives at the org level, so none of them match: the command
exits 0, prints the issue, and applies nothing. Repo-local labels
(wayfinder:*, ready-for-agent) work normally, which makes the failure look
intermittent instead of categorical.
Upstream tea fixed this in v0.15 — modules/task/labels.go now queries ListOrgLabels alongside the repo labels. nixpkgs pins 0.14.0, so this note
expires when tea is bumped. tea labels has the same repo-only limitation and
will not show the org set; tea api orgs/ShadowsOverWestgate/labels will.
The second bullet is the more durable half: re-read a label change before
believing it. An earlier version of this branch confidently documented the
opposite cause, because a label that a human had applied by hand was read back
as proof that the CLI had applied it. tea issues ls -o json exposes a labels
field; a zero exit code does not.
Identical addition in all seven repos carrying docs/agents/issue-tracker.md.
`tea issues edit --add-labels` and `--remove-labels` resolve label names against
the repository's own label set only. Every `Kind/*`, `Priority/*`, `Reviewed/*`
and `Status/*` label lives at the org level, so none of them match: the command
exits 0, prints the issue, and applies nothing. Repo-local labels
(`wayfinder:*`, `ready-for-agent`) work normally, which makes the failure look
intermittent instead of categorical.
Upstream tea fixed this in v0.15 — `modules/task/labels.go` now queries
`ListOrgLabels` alongside the repo labels. nixpkgs pins 0.14.0, so this note
expires when tea is bumped. `tea labels` has the same repo-only limitation and
will not show the org set; `tea api orgs/ShadowsOverWestgate/labels` will.
The second bullet is the more durable half: re-read a label change before
believing it. An earlier version of this branch confidently documented the
opposite cause, because a label that a human had applied by hand was read back
as proof that the CLI had applied it. `tea issues ls -o json` exposes a `labels`
field; a zero exit code does not.
Identical addition in all seven repos carrying `docs/agents/issue-tracker.md`.
`tea issues edit --add-labels` and `--remove-labels` resolve names against
the repo's own label set only, so `Kind/*`, `Priority/*` and the rest of
the org set match nothing. The command exits 0, prints the issue and
changes nothing — no error to notice. Repo-local labels work, which makes
the failure look intermittent rather than categorical.
Upstream fixed this in v0.15 (`modules/task/labels.go` also queries
`ListOrgLabels`); nixpkgs pins 0.14.0, so the note expires on a bump.
Also states the general rule the miss came from: re-read a label change
before believing it. Exit 0 is not evidence.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
archvillainette
changed title from docs(agents): warn that tea label edits are not visible to an immediate read-back to docs(agents): record that tea 0.14 cannot apply org-level labels2026-08-05 10:58:31 +00:00
archvillainette
scheduled this pull request to auto merge when all checks succeed 2026-08-05 11:00:05 +00:00
xtul
approved these changes 2026-08-05 11:01:09 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
tea issues edit --add-labelsand--remove-labelsresolve label names againstthe repository's own label set only. Every
Kind/*,Priority/*,Reviewed/*and
Status/*label lives at the org level, so none of them match: the commandexits 0, prints the issue, and applies nothing. Repo-local labels
(
wayfinder:*,ready-for-agent) work normally, which makes the failure lookintermittent instead of categorical.
Upstream tea fixed this in v0.15 —
modules/task/labels.gonow queriesListOrgLabelsalongside the repo labels. nixpkgs pins 0.14.0, so this noteexpires when tea is bumped.
tea labelshas the same repo-only limitation andwill not show the org set;
tea api orgs/ShadowsOverWestgate/labelswill.The second bullet is the more durable half: re-read a label change before
believing it. An earlier version of this branch confidently documented the
opposite cause, because a label that a human had applied by hand was read back
as proof that the CLI had applied it.
tea issues ls -o jsonexposes alabelsfield; a zero exit code does not.
Identical addition in all seven repos carrying
docs/agents/issue-tracker.md.f958436238to27005622e4docs(agents): warn that tea label edits are not visible to an immediate read-backto docs(agents): record that tea 0.14 cannot apply org-level labels