yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

scripts/issue.sh claim is unusable: it needs read:user for a lookup nothing else needs #130

New Issue
Closed
opened 2026-08-19 14:22:14 +00:00 by logan · 1 comment
logan commented 2026-08-19 14:22:14 +00:00
Collaborator
Copy Link
Copy Source

Report

./scripts/issue.sh claim <n> fails outright with:

issue.sh: token does not have at least one of required scope(s),
required=[read:user], token scope=write:package,write:issue,write:repository

Claiming is the one step CLAUDE.md requires before the first edit, and it is
the step that tells the collaborator the work is taken while it is being done.
So the whole documented workflow is blocked by its own tooling, and the fallback
is to do the three halves by hand — which is exactly the "a claim somebody else
has to go looking for" that claim exists to prevent, and easy to do partially.

Findings

  • claim calls me() (GET /user) purely to resolve the current username for
    the assignee, and /user needs read:user.
  • Nothing else in issue.sh needs the scope: list, search, show,
    comment, label, close and depends all work on the current token.
    mine needs it for the same reason.
  • The by-hand equivalent is three calls, and all three are needed or the claim
    is invisible to one of the three places people look:
    PATCH /issues/<n> with {"assignees":["<user>"]},
    issue.sh label <n> "+Status/In Progress", and issue.sh comment <n>.

Direction

Two possible fixes, and the second is probably the right one:

  1. Re-issue GITEA_TOKEN with read:user. Fixes it everywhere at once but
    leaves the script demanding a scope it needs for one lookup.
  2. Let the username be supplied — GITEA_USER, falling back to me() only
    when it is unset. claim then works on a write:issue-only token, which is
    the least privilege the job actually needs, and mine can use the same
    value.

Either way claim should fail before it does any of the three halves, which
it does today, so there is no partial-claim risk to clean up.

**Report** `./scripts/issue.sh claim <n>` fails outright with: ``` issue.sh: token does not have at least one of required scope(s), required=[read:user], token scope=write:package,write:issue,write:repository ``` Claiming is the one step CLAUDE.md requires *before the first edit*, and it is the step that tells the collaborator the work is taken while it is being done. So the whole documented workflow is blocked by its own tooling, and the fallback is to do the three halves by hand — which is exactly the "a claim somebody else has to go looking for" that `claim` exists to prevent, and easy to do partially. **Findings** - `claim` calls `me()` (`GET /user`) purely to resolve the current username for the assignee, and `/user` needs `read:user`. - Nothing else in `issue.sh` needs the scope: `list`, `search`, `show`, `comment`, `label`, `close` and `depends` all work on the current token. `mine` needs it for the same reason. - The by-hand equivalent is three calls, and all three are needed or the claim is invisible to one of the three places people look: `PATCH /issues/<n>` with `{"assignees":["<user>"]}`, `issue.sh label <n> "+Status/In Progress"`, and `issue.sh comment <n>`. **Direction** Two possible fixes, and the second is probably the right one: 1. Re-issue `GITEA_TOKEN` with `read:user`. Fixes it everywhere at once but leaves the script demanding a scope it needs for one lookup. 2. Let the username be supplied — `GITEA_USER`, falling back to `me()` only when it is unset. `claim` then works on a `write:issue`-only token, which is the least privilege the job actually needs, and `mine` can use the same value. Either way `claim` should fail *before* it does any of the three halves, which it does today, so there is no partial-claim risk to clean up.
logan added the
Priority
Medium
3
Reviewed
Confirmed
1
Kind/Bug labels 2026-08-19 14:22:14 +00:00
yonlu self-assigned this 2026-08-19 17:17:58 +00:00
yonlu added the
Status
In Progress
 label 2026-08-19 17:17:58 +00:00
yonlu commented 2026-08-19 17:17:59 +00:00
Owner
Copy Link
Copy Source

Starting work on this.

Starting work on this.
logan closed this issue 2026-08-19 19:08:46 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-19 19:08:55 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Kind/Bug
Priority
Medium
3
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees yonlu
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#130