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

suchademon · April 18

Hello,
I found the following in the CLI version 2.27.0 while I upgraded my wrapper scripts to support the new CLI version:

$ op item edit APP_xxxxxxxx.eu --tags=''
ID:          nqehrspxxxxxxxxxxxxxxxxxx
Title:       APP_xxxxxx.eu
Vault:       Vault1 (xxxxxxxxxxxxxxxxx)
Created:     2 years ago
Updated:     now by xxxxxxx
Favorite:    false
Tags:        [],c5b4df28f1ef8d04946a96ececf9478d00a1b508
Version:     28
Category:    LOGIN
Fields:
...

Copy from op item edit --help:

      --tags tags                    Set the tags to the specified (comma-separated) values. An
                                     empty value will remove all tags.

So either the documentation needs to be updated, or there is a bug, at least it looks like this.

According to op item edit --help the argument --tags="" or --tags should clean all tags, but it does not, it creats a new version.

Also if I place a real value in there, it does not replace the existing tags, it is appending it:

$ op item edit APP_anio.eu --tags='asdf'
ID:          nqehxxxxxxxxxxxxxxxxxx
Title:       APP_xxxxxxxxxx.eu
Vault:       Vault1 (xxxxxxxxxxxxxxxxxxxxxxxx)
Created:     2 years ago
Updated:     now by xxxxxxx
Favorite:    false
Tags:        [],asdf,c5b4df28f1ef8d04946a96ececf9478d00a1b508
Version:     29
Category:    LOGIN
Fields:
...

I tried to use the delete syntax for custom fields, if that would do the trick but of course not:

$ op item edit APP_xxxxxxxxxxxxxx.eu 'tags[delete]'
[ERROR] 2024/04/18 21:26:09 cannot delete "tags" because it is a built-in field

Is that on purpose now that tags get appended instead of replaced?
If yes, how do I delete all tags from the CLI on one item? (As I need this to keep pass with 1pass in sync and the UIDs for this are placed currently in the tags filed)

Btw while I was writing this, I tested also this:

$ op item edit APP_xxxxxxxxxxxxxx.eu
ID:          nqehrxxxxxxxxxxxxxxxxxxxxxxxxxx
Title:       APP_xxxxxxxxxxxxxxxxxxxxxx.eu
Vault:       Vailt1 (xxxxxxxxxxxxxxxxxxxxxxxxx)
Created:     2 years ago
Updated:     now by xxxxxxxxxxxxxxxx
Favorite:    false
Tags:        [],asdf,c5b4df28f1ef8d04946a96ececf9478d00a1b508
Version:     31
Category:    LOGIN
Fields:

Do you see it? The version counter increased (form 29 to 31 as I did 2 test of the same command) even I haven't specified anything to change.
Could it be that there is a general bug in op edit ?

Did not tried op create, but can if needed

OS: Debian 13
Kernel: 6.6.15-2
1Password CLI: 2.27.0

Many thanks in advance

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser: Not Provided

suchademon · June 6

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

suchademon · June 6

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

suchademon · June 10

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

HideousChowtime · June 22

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 %

suchademon · July 30

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:

$ 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):

$ 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

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

Comments