Skip to content

Are 1password shell plugins promoting bad security behavior #617

Open

Description

@pulasthibandara

op CLI version

all

Goal or desired behavior

For platforms that support short-lived access tokens through their own CLI tools (ex: gh/aws), the 1password plugin accepting potentially long-lived access token potentially degrades security posture of these tools. For a user unaware of the difference, this is a potential risk.

Examples:

  • Aws: aws sso login --sso-session <account-name> creates short lived tokens
  • Github: gh auth login craete a token for the shell and stores in system keychain

Current behavior

1password requests the user to create a token (potentially not-expiring due to the steps involved in the manual propcess).

Relevant log output

Activity

  1. added
    op-cliFunctionality to be implemented in 1Password CLI. Needs to be done by 1Password Developers.
    on Jun 26, 2026
  2. added
    questionFurther information is requested
    and removed
    op-cliFunctionality to be implemented in 1Password CLI. Needs to be done by 1Password Developers.
    on Jun 30, 2026
  3. scottisloud commented on Jun 30, 2026

    @scottisloud
    Contributor

    Hi @pulasthibandara

    At the end of the day I think it comes down to being thoughtful about the specifics of your security posture, threat model, and risks. And I think it requires thought about what makes sense for a specific CLI tool. As you note, different CLI tools have different ways of authenticating, and different tools carry different risk.

    But given the choice between a long-lived token in plaintext in ~/.config or persistent in an environment variable, or using a 1Password Shell Plugin, the shell plugin is a safer choice.

    But where a CLI offers some more secure auth methods such as an SSO login with short-lived tokens, then shell plugins may not offer benefit or may be inferior to those other auth methods.

    What it comes down to is: not every tool that exists in the world will excel in every situation every time. Shell plugins are no different. There are plenty of places where those more secure authentication options may not be available for a tool, or may be available but not accessible to a given user (e.g., if you don't have SSO, then SSO-based auth doesn't help you).

    Security is a spectrum and it's highly contextual. We all have to be careful and thoughtful about which tools we use, when we use them, and how.

    You have to decide whether a shell plugin is a security improvement over other auth methods for a given CLI tool or not, and that's a decision that we can't make for you. All we can do is provide options and tools for you to use at your discretion.

    This is a really important point you are making, and I'm glad you shared it. We all need to think about this and make intentional security decisions for the tools we use and the context we use them in.

    Thanks for sharing your thoughts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions