Is there currently a bug in the `--tags` argument for the current CLI 2.27.0 version?

Hello, any one there from the 1Password cli dev team?
Would be amazing if someone could have a look at this please.

Or if somebody knows how to file a issue/open a bugrequest for the cli dev team, please let me know.

Many thanks

fyi, have had a look at the latest release notes for 2.28.0 and 2.29.0 but still decided to test it with current stable version of CLI (2.29.0) and got the same result. tag got added instead of replaced and deletion of tags also not working

Hello @AndyW1P ,
saw you replying to other channels in the CLI topic and would like to ask you when you have time to have a look at the above.

Many thanks in advance.

br

Hi @suchademon ,

I also have this problem. I found a solution. It was a variation on what the pubs suggested. The trick is to enclose the empty tags statement in single quotes.

Example:

op item edit "ZZZ Test DELETEABLE" 'tags='

Below I provide a longer version of a console log showing the same approach. The original Password item has 4 tags, picked at random. Please note the following:

• I use the op read feature to quickly read the tags in the CLI
• I was able to verify this solution in other more rigorous code (not shown)

```
/tmp/experiment1 % op item get "ZZZ Test DELETEABLE" --format json
{
"id": "muy2lvljbycgtto5dg7ddh77gu",
"title": "ZZZ Test DELETEABLE",
"tags": ["estimate", "murky", "twiddling", "wicked"],
"version": 3,
"vault": {
"id": "nlv4anz4x763hlyyp42hdjzzbm",
"name": "Private"
},
"category": "PASSWORD",
"created_at": "2024-06-21T16:19:15.98229-05:00",
"updated_at": "2024-06-21T16:19:18.22646-05:00",
"additional_information": "Fri Jun 21 16:19:15 CDT 2024",
"fields": [
{
"id": "password",
"type": "CONCEALED",
"purpose": "PASSWORD",
"label": "password",
"value": "handclasp whacky herbal eastern",
"reference": "op://Private/ZZZ Test DELETEABLE/password",
"password_details": {
"strength": "FANTASTIC"
}
},
{
"id": "notesPlain",
"type": "STRING",
"purpose": "NOTES",
"label": "notesPlain",
"reference": "op://Private/ZZZ Test DELETEABLE/notesPlain"
},
]
}
/tmp/experiment1 % op signin && op read "op://Private/ZZZ Test DELETEABLE/tags"

estimate, murky, twiddling, wicked
/tmp/experiment1 % op item edit "ZZZ Test DELETEABLE" 'tags='

ID: muy2lvljbycgtto5dg7ddh77gu
Title: ZZZ Test DELETEABLE
Vault: Private (nlv4anz4x763hlyyp42hdjzzbm)
Created: 22 minutes ago
Updated: now
Favorite: false
Version: 4
Category: PASSWORD
Fields:
password: handclasp whacky herbal eastern
/tmp/experiment1 % op signin && op read "op://Private/ZZZ Test DELETEABLE/tags"

/tmp/experiment1 %

```

Hello @HideousChowtime ,
loooool, yea tested the workaround and it yea, it does the job.

But still looks like a bug to my, as the parameter is still getting accepted and is mentioned in the help pages.

Thank you very much for that, finally I can get my automation for bidirectional syncing of pass and OP back online again \o/

Btw if other persons see this, to apply multible tags, just seperate them using colons:

bash
$ op item edit ${item_name} 'tags=tagNr1,tagNr2'


and if you want to use it with variables, it works like this (tested on 2024-07-30 with OP version 2.29.0):

bash
$ testtag="tagNr1,tagNr2"
$ op item edit ${item_name} 'tags='"${testtag}"


This will create the both mentioned tags in the variable testtag (also working if spaces are in the tag name as long as you keep of course the double quotas.

Still looking forward when that bug is fixed