ZSH completions when using glab plugin

Platform or tool

GitLab

Desired or expected behavior

Hi team, really enjoying the GitLab 1password plugin. https://developer.1password.com/docs/cli/shell-plugins/gitlab

One thing I noticed once I installed the glab shell plugin is that my completions stopped working, since op aliases glab

I had to add setopt completealiases to my ~/.zshrc file so zsh does not expand aliases before performing completion.

I was thinking if it would be worth mentioning here: https://developer.1password.com/docs/cli/shell-plugins/gitlab ?

Current behavior

Completions don't work by default with zsh + op

Relevant log output

No response

op CLI version

2.8.0-beta.10

Have not tested, but I would guess this is the same for all shells (except maybe Fish, Fish shell is pretty good about doing that kind of stuff by default) and all Shell Plugins.

Maybe plugins.sh should set the correct equivalent of completealiases in all shells, or otherwise mention it somewhere in the docs that applies to all shell plugins.

Some findings from looking into this a bit:

For zsh, you just need to setopt completealiases
For fish, no changes are needed, Fish shell follows alias completions by default
For bash, there is not any equivalent of setopt completealiases, so you would need to do one of a few things (see below)

For these reasons, I think the best approach is to document it, rather than trying to set it automatically, because the plugins.sh file has no shebang line (e.g. #!/usr/bin/env bash) and so it runs in the user's own shell environment. Trying to set it automatically would mean adding some shell detection, in a syntax that is compatible with all of zsh, bash, and fish, which might be complex; fish syntax is mostly compatible with bash/zsh but not fully.

Options for bash completions:
Disclaimer: I've not validated these, we'll need to audit them before we can officially recommend them. For now, use at your own risk.

For ZSH we can do the following:

function _glab_command () {
  op plugin run -- glab $@
}

alias glab="_glab_command"
compdef _glab _glab_command

I no tested it yet for glab, but I did it for "doctl" and it works well

@jrpedrianes

I'd prefer not to setopt completealiases in zsh as that would mess up completions of other aliases that include command line args.

I tried this for gh and while @jrpedrianes solution worked, it asked for authentication on every completion, unless I switched the security settings from "ask approval for each new application and terminal session" to "ask approval for each new application". I think this is because a new subshell is spawned for each function call?

My interim solution has been to update the op completion functions to call _gh directly – see this gist for the changes. In particular, within _op_plugin_run:

  case "$line[1]" in
  gh)
    _gh
    ;;
  esac

This should work for _glab as well. There's probably a better way to make it work for all completions, but I haven't found it yet.

Edit: the general solution for zsh looks to be as simple as replacing the lines above with:

_dispatch "$curcontext" "$line[1]"

@aaronkollasch

@aaronkollasch's solution above works for me for op plugin run glab:

% op plugin run glab #TAB
alias         -- Create, list and delete aliases
api           -- Make an authenticated request to GitLab API
...

However op's aliases default to including the -- separator, e.g. op plugin run -- glab, which doesn't work and autocompletes files/dirs instead:

% op plugin run -- glab #TAB
bin/               Desktop/           Downloads/
...

zsh 5.9. op autogenerates the aliases, I'd prefer not to mess with those manually. Any idea what could be the issue here? Thank you!

@Forst

@Forst I finally found the problem – there was an extra -- hanging around before the command in the zsh variable $words.

Adding the following lines before _dispatch "$curcontext" "$line[1]" fixes the issue:

  if [[ "$words[1]" == "--" ]]; then
    shift words
  fi

I've also updated the gist. This should get things to work properly with op's autogenerated aliases, i.e. op plugin run -- glab

fix dispatch of zsh autocomplete for op plugins

Related: #433

The thing that works reliably for me is also monkey patching op completion function with:

function _op_plugin_run_fix() {
    for (( i=2; i < CURRENT; i++ )); do
        if [[ ${words[i]} == -- ]]; then
            shift $i words
            (( CURRENT -= i ))
            _normal
            return
        fi
    done

    # run original op completion
    _op
}

function __load_op_completion() {
  local op_completion_fn="$(op completion zsh)"
  local fix_fn="$(which _op_plugin_run_fix)"

  # replace all references to _op with _op_plugin_run_fix (except for the function definition)
  local patched_op=$(sed -E -e 's/\b_op\b([^()]|$)/_op_plugin_run_fix\1/g' <<< $op_completion_fn)

  echo -e "$patched_op\n\n$fix_fn"
}

eval "$(__load_op_completion)"

The only problem with it is that I need to use eval instead of keeping it on fpath.
With fpath the guard in _op on $funcstack means that when loading completion for the first time I have to press <TAB> twice.

@punk-dev-robot

@punk-dev-robot -- many thanks for the solution!

A tweak for OS X users. For this function:

function __load_op_completion() {

OS X default sed does not support \b , instead use [[:<:]] and [[:>:]]:

  # replace all references to _op with _op_plugin_run_fix (except for the function definition)
  local patched_op=$(sed -E -e 's/[[:<:]]_op[[:>:]]([^()]|$)/_op_plugin_run_fix\1/g' <<< $op_completion_fn)

Hi everyone, thanks for the detailed reports and workarounds.

What's going on
The completion failures documented in this issue stem from behaviours of certain shells (e.g., Zsh) when it comes to aliases. Since this is a shell-determined behaviour, this isn’t something we can directly fix.

What we plan to do:

Documentation — We agree it’s worth calling out explicitly on the shell-plugin docs the current workarounds for specific shells: zsh (setopt completealiases and tradeoffs), fish (usually fine without extra config), and bash (no direct completealiases equivalent).
- We will discuss internally the best place for this to be documented and I've already opened an internal ticket to track that discussion.
Investigate options for improving the experience at the op level.
- We will be doing some research and testing to see determine the viability and scope of changes required.

Since this is not a bug, but rather the intended behaviour of zsh, I'll be removing the bug label.

Thanks for the discussion and the proposed workarounds. We will keep this issue open and update when we have new information to share.

If my reading of #122 (comment) is correct, then bash, which is the default shell of any Ubuntu system, also suffers from this failure. Add that the OS X default shell is zsh, and the current implementation borks anyone on OS X and anyone running a thin Ubuntu (e.g. WSL2 or in a Docker container), unless extra steps are taken.

While I agree shell detection is overkill, making it work on bash seems to be a minimum. I hope that is included in your #2 above.

But don't mind me, I've already uninstalled op because of this and many other issues.

@HarmonicDisturbance

Hi @HarmonicDisturbance

Indeed, ideally we can address both zsh and bash.

@HarmonicDisturbance If you are still a 1Password user and have programmatic access needs, check out our SDKs and 1Password Developer Environments. These are relatively new, so may have slid under your radar, and between them, offer a few different approaches to provisioning secrets

Both SDKs and environments can be used with Service Accounts too to facilitate unattended and scoped access a bit more securely.

Thanks for the additional feedback!

Hi everyone,

Thanks for the ongoing feedback. We're working on a fix in 1Password CLI now. We don't have a release timeline to share yet; I'll follow up here once we have a clearer picture of when it will ship.

A fix for this shipped in version 2.35 of the 1Password CLI (release notes).

Navigation Menu

Repository navigation

ZSH completions when using glab plugin #122

Platform or tool

Desired or expected behavior

Current behavior

Relevant log output

op CLI version

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ZSH completions when using glab plugin #122

Description

Platform or tool

Desired or expected behavior

Current behavior

Relevant log output

op CLI version

Activity

mrjones2014 commented on Dec 20, 2022

mrjones2014 commented on Jan 3, 2023

jrpedrianes commented on Jan 16, 2023

aaronkollasch commented on Feb 22, 2023

Forst commented on Oct 31, 2023

aaronkollasch commented on Feb 26, 2024

mrjones2014 commented on Apr 22, 2024

punk-dev-robot commented on Jun 22, 2024

renet10 commented on Feb 24, 2026

scottisloud commented on May 14, 2026

HarmonicDisturbance commented on May 14, 2026

scottisloud commented on May 14, 2026

scottisloud commented on May 21, 2026

scottisloud commented on Jul 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions