Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 
  • Community
  • Q&A
  • Jira
  • Questions
  • acli jira workitem assign fails with "unexpected error" for a specific user, while REST API work

acli jira workitem assign fails with "unexpected error" for a specific user, while REST API work

Rickard Fredman
July 6, 2026

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? 

2 answers

2 votes
Martin Runge
Community Champion
July 6, 2026

Hi @Rickard Fredman

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

0 votes
Arkadiusz Wroblewski
Community Champion
July 6, 2026

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🤠

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
TAGS
AUG Leaders

Atlassian Community Events