Hey @bradical , thank you for reaching out to us!

This is a known limitation of the shell plugins, and getting these to work in scripts and non-interactive calls is definitely on our roadmap!

In the meantime, there are some workarounds that you can use:
* export the alias directly in your script - begin your script with alias aws=op plugin run -- aws
* source the plugins.sh file in your script - in your zshrc or bashrc or config file, you will find a statement such as source ~/.op/plugins.sh. Including the same statement at the beginning of your script will make sure that all your configured aliases are available in there too.

Hope these solutions will work, as a stopgap. We'll keep posted with any developments around this! Let us know if we can help with anything else.

Best,
Horia

@"Horia.Culea_1P" I hope 1Password adds this feature as fast as possible! I don't know how much the work has gone through, but would you mind if you could share what use cases the new feature covers? Is 1Password's "proxy" command intended to be used only in shell scripts or in any executable programs? I wish for the second that gives users options.

I suggest the following approach: allow users to specify the desired plugin to use and the exact binary file path, like this op plugin run --target aws -- /opt/homebrew/bin/aws. Users deserve more control over what to use.

Here is my current workaround for now (aws as an example). Put this script file into the one of entries in the $PATH, name it aws, and make sure this file precedes the original one in priority.

```

!/bin/sh

if [ "${1-}" = '@FROM_PROXY' ]; then
shift
exec /opt/homebrew/bin/aws "$@"
else
exec op plugin run -- aws '@FROM_PROXY' "$@"
fi
```

The@FROM_PROXY trick is here to prevent cyclic execution.