On acli 1.3.22-stable (OAuth auth), acli jira workitem assign (and edit --assignee) consistently fails when assigning an issue to a specific user — including @me, the user's email, and the raw account ID. The identical assignment succeeds via the Jira REST API with the same account, so this appears to be a bug in the CLI's assignee code path, not a permissions or auth problem.
Environment
- acli version: 1.3.22-stable
- Auth type: OAuth (scopes granted include jira-work "create and edit issues")
- OS: macOS (darwin 24.6.0)
- Site: Jira Cloud
What fails
Every one of these returns ✗ Failure: <KEY> can't be assigned: unexpected error, trace id: <id>:
acli jira workitem assign --key ABC-123 --assignee "@me" --yes
acli jira workitem assign --key ABC-123 --assignee "me@example.com" --yes
acli jira workitem assign --key ABC-123 --assignee "712020:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" --yes
acli jira workitem edit --key ABC-123 --assignee "@me" --yes
acli jira workitem edit --key ABC-123 --from-json assignee.json --yes
What works
- acli jira workitem view and search — ✅
- acli jira workitem edit --summary "..." (a normal field write) — ✅
- acli jira workitem assign --key ABC-123 --assignee "default" --yes — ✅ (sets it to the project's default/Unassigned)
So reads work, general field edits work, and clearing/defaulting the assignee works — only assigning a named user fails.
Proof it's not permissions/auth — REST API succeeds
Using the same account (an API token for the same user), the dedicated assignee endpoint works immediatel
curl -s -u "me@example.com:$JIRA_API_TOKEN" -X PUT \
"https://MYSITE.atlassian.net/rest/api/3/issue/ABC-123/assignee" \
-H "Content-Type: application/json" \
-d '{"accountId": "712020:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}'
# → HTTP 204 No Content, assignee is set correctly
GET /rest/api/3/myself with the same credentials returns HTTP 200 and the matching account ID, and after the PUT the issue shows the correct assignee.
Conclusion / question
Because --assignee default and the REST PUT .../assignee both succeed while --assignee <user> fails with a generic backend error, the bug looks specific to how acli builds/sends the set-named-assignee request. Is this a known issue, and is there a fix or workaround beyond falling back to the REST API?
Welcome to the Atlassian community!
There's a global issue impacting some of our sites as well. You can subscribe to updates here: https://jira-service-management.status.atlassian.com/incidents/91wr4x0zhhyj. For the latest status, please visit https://status.atlassian.com.
Cheers, Martin
Hello @Rickard Fredman
Like @Martin Runge already mentioned, the endpoints you are using were heavily impacted by today’s incident.Especially Assignee and overall user access.
Best,
Arek🤠
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.