Forum Discussion

suitewill's avatar
suitewill
New Contributor
11 months ago

Injecting secrets with op command does not work with Work Organization account

I am experiencing the same issue as discussed on this closed thread: https://1password.community/discussion/137489/how-to-inject-secrets-int-oenvironment-variables-when-using-multiple-accounts ...
CLI
1P_Phil's avatar
1P_Phil
Icon for Moderator rankModerator
7 days ago

Hi michaelyork​, suitewill​ - (et. all),

I think at this point it is up to us to consolidate the "why" into a case for why it is important to fix this.  I have a few assumptions (below), but I would like to see if there are additional reasons why.

Developer Workflow

  • adds friction: having to pass --account/OP_ACCOUNT breaks portable scripts and team docs when teammates have different default accounts. Slows down onboarding/ramp of developers.
  • URI assumptions: The op://vaultID/item/field ref looks globally unique; there’s no place to add account, so they expect the tool to infer it.

 

Precedent: existing tools infer the full scope from the resource identifier; users expect the same here.

  • AWS CLI (s3://my-bucket/)
  • HTTP ...


Least‑surprise: if a vault name clearly matches only one signed‑in account, resolving it without extra flags feels natural.

(Tangentially) UI Cohesion

  • Mental model: “I can see the Work vault in 1Password → a reference to that vault should just work.”
  • Desktop UI shows all signed‑in accounts unified, so users assume the CLI will behave similarly.

 

  • michaelyork's avatar
    michaelyork
    Frequent Contributor
    7 days ago

    Hey 1P_Phil​ – not sure I understand. It just...doesn't work right now? What's the case to be made?

    If you have multiple accounts connected to your CLI (whether by desktop app integration, or by signing in directly via CLI), there is no way to use `op run` with the non-default account (and there is no way to set the default account).