Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Bun cannot read 1Password-mounted .env files directly
Hi everyone, I’m experimenting with 1Password Local Environment Files for local development, but I ran into an issue when using Bun. Even though I can cat .env and see the correct contents, running: bun --print process.env returns nothing — Bun does not pick up any of the variables. After some testing, I found that copying the content into a normal file makes it work: cp .env .env.development bun --print process.env The problem seems to be that Bun cannot reliably read virtual/mounted files (pipes/FUSE mounts). Workarounds that work: Use dotenv/x and use `dotenvx run -- bun run ...` Use `op run --environment -- bun run ...` Since https://bun.com/docs/runtime/environment-variables, it should just work with the mounted file, whereas these approaches result in adding extra commands or wrappers all around the monorepo. It would be great if 1Password could provide guidance on using Bun (or other tools that expect standard filesystem .env files) with mounted local env files. Has anyone else run into this with Bun or similar tools? Thanks!
FR: Allow Environments to reference Vault Items
Description: Currently, 1Password Environments and Vault Items are two completely separate systems with no connection between them. This creates a fundamental problem for professional workflows: Environments provide fast, secure secret delivery via Named Pipes – great for local development Vault Items provide rotation, audit trails, access control, and CLI management – great for operations But you have to choose one or maintain both in parallel, which means either giving up rotation or giving up fast secret delivery. Proposed Solution: Allow an Environment variable to be linked to a Vault Item. The Environment would act as a structured view over Vault Items, not a separate data store. Benefits: Single source of truth – secrets live in Vault Items, Environments just expose them Rotation works automatically – rotate the Vault Item, the Environment reflects the change immediately Audit trail remains intact – all access and changes tracked in Vault Items Named Pipe delivery stays fast – no change to the developer experience
Environments should quote .env values
I just started experimenting with Environments to mange my .env files. I use https://direnv.net/ to load my .env files into my shell and it immediately started complaining. As it turns out, my previous plain text .env had quoted values in some cases, for instance a secret that contains a "&" and another one with ")". It would be nice if Environments either quoted values by default or offered the option to do so. Would also be nice if my #comments were preserved on import.
1Password 'Environments' and monorepos/collocated deployment configuration
I'm fiddling with Environments today to see how it would work for my workflows, and immediately ran into two fairly significant blockers: ## Multi-environment orchestration The only way I can see to get an environment-ID into an `op run` command is as a flag/env-var pre-dispatch; but for something like Ansible, where an entire inventory of tasks require a complex mapping of projects/apps/secrets/teams, that would require centralizing all of the "environment IDs" into one top-level invocation, irrespective of what actual tasks the given Ansible command might run. (This isn't Ansible-specific, "ansible" here could be any complicated orchestration tool that makes intelligent decisions about what to do for multiple potential environments.) Yes, I'm sure the blessed path, or what would be ideal for 1P, is that each possible orchestration tool in existence use the 1P SDK, have a built-in, or a plugin, or something like that, so that 1P is separately queried for each target/environment - but there will always be *some* tool that doesn't (up to an ad-nauseum target of "all of our deployment is bespoke by scripting.") At the moment, this situation is still better served by the previously-extant `op://` references in static env-files: they're "discoverable" during the process, in that anything/everything present in the environment is substituted at launch-time; but that's also worse in its own way - they're less isolated, and it leaves a similar "collect all the environment for all possible targets first, before executing the orchestrator." I don't necessarily have a specific feature-request or a way I imagine this working, right now; I just wanted to surface the annoyance for you to consider as you're working on the feature. (Related issue, similar vein, but not exactly the same architectural problem - there's only one `OP_ENVIRONMENT_ID` env-var; and while the `op run` can take multiple environment-flags, that's again a single-point-of-invocation issue. Ways to construct partial environment-based assignments pre-invocation is missing here, unless you store them manually and construct some method of passing them to `op run` - i.e. there's no equivalent of `op://` references, where multiple different scripts and wrappers can all happily contribute multiple `op://` references into the environment without coordinating, and one final `op run` can consume/resolve all of them for some sort of commit/apply process.) ## Duplication of secrets This one is the much bigger one, and kinda a dealbreaker, at least for me. For basically any given secret, I *already* have a central, authoritative 1Password entry as the source-of-truth for that - it has version-history, shared notes, access permissions for people, it autofills browsers and logins and CLI invocations ... but at the moment, "1Password Environments" only allows me to put in 'dumb strings' as variable-values. Which means that I need to, say, *duplicate* a database-user password in both 1. a 1Password vault-entry, and 2. a 1Password environment-variable. (... and then document somewhere that it's been duplicated; and establish process to make sure anybody modifying it knows to go modify both; and, and, and ...) I assumed when starting this out that the entire point of 1Password environments would be, effectively, something like a templating system: include, inline in the definitions, the equivalent of `op://` references to other *existing* secrets, such that they're filled in when actualized onto the filesystem or requested from SDK apps. (Think, "username" and "password" are already in a database vault-entry; so the `DATABASE_URL` env-var configures how to construct the database-url from those keys.) Without that functionality, I'm actually a little lost as to the value/purpose of environments (not to criticize anyone's hard work, or anything; I'm sure there's a pictured use-case that makes sense, I'm just not currently managing to see it, haha.) So, the request here is a little more direct: let me configure references to other 1Password items in environment-variables - at a minimum as a 1:1 correlation (i.e. `DB_USER` being configured directly to `op://Team Secrets/Database - Prod/Postgres/username`); but ideally, with some minimal templating, so additional content/simple structure can be hardcoded into the env-vars that are *mostly* derived from secrets (Postgres connection-strings/URLs; or derivation from other env-vars to avoid duplication on that end either, such as configuring `USER_PW` to `op://Team Secrets/${HOSTNAME}/password`.) Hope this is helpful feeback about the issues somebody ran into in the real-world trying to apply this! I *do* love the promise of ditching env-files-full-of-`op://`-references-hardcoded-into-repos, in favour of something more auditable / sited-with-the-secrets-in-question / dynamically-configurable.
Introducing new .env file support in 1Password
Today, we’re introducing a first-of-its-kind feature available in the 1Password Desktop app. With the new local .env file destination in 1Password Environments, you can securely use and share .env files across your team, without rewriting how your app loads credentials. Here’s why it matters: Zero plaintext secrets on disk: Secrets are loaded into applications on demand. You can’t accidentally commit them. No cumbersome sharing of secrets: Teammates get instant access - no DMs or copying secrets. Built for teams: Version history, access control, and automatic updates - all in one place. Offline access: No more internet connection required to load secrets from 1Password. Secrets are sourced directly from the desktop app's local cache. Now available in beta on Mac and Linux. Interested to see it in action? Watch the demo video below. Video not displaying? Watch it here. 💬 Share feedback, get swag We want your input on what to build next: CI/CD integrations? Docker support? Something else? 📖 Read the docs to get started 👉 Join the discussion in the 1Password Developer Community 🧢 The first 10 developers to start a discussion on the 1Password Developer Community Hub to share feedback by October 31st will get exclusive 1Password swag. Be sure to tag your post with beta-environments.1Password Environments should enable grouping environments by service
Hi, The new .env management feature in 1Password is incredibly handy, and I can definitely see us adopting it for our backend services. It makes working with environment variables much more convenient. That said, I’d like to share some concerns regarding scalability. We have several services, each with multiple environments such as development, staging, production, and feature-specific environments. In 1Password Environments, these all of these environments appear side by side in a single list, regardless of which service they belong to. This results in naming schemes like "[Service]: [Environment]". While workable, this approach becomes harder to manage as we scale across multiple services. To illustrate, I’ve included a screenshot below showing what I anticipate the structure to look like in our setup. In this case, Service A and Service B have no relation to each other, yet their environments are intermingled. A way of grouping services would make this much clearer and easier to navigate. Best regards, Simon B. Støvring1Password CLI Bug Report: Service Account Cannot Read Environments
Summary op environment read and op run --environment return "Environment was not found" when authenticated with a Service Account that has Read access to the Environment. Desktop app authentication works correctly with the same Environment ID. Environment op CLI version: 2.33.0-beta.02 OS: macOS 15.3 (arm64) 1Password Desktop App: 8.12.2 Account type: Individual (my.1password.com) Steps to Reproduce Create a 1Password Environment "AI Agent" with variables (e.g., BRAVE_API_KEY) Create a Service Account "Ghossty" with: Vaults: Dev (Read) Environments: AI Agent (Read) Export the Service Account token: export OP_SERVICE_ACCOUNT_TOKEN="<token>" Run: /usr/local/bin/op environment read <environment-id> Expected Result BRAVE_API_KEY=<value> GITHUB_PAT=<value> Actual Result [ERROR] 2026/02/18 18:41:55 bad input passed by the user: Environment was not found Workaround Confirmation Desktop app authentication works correctly with the same Environment ID: OP_SERVICE_ACCOUNT_TOKEN= /usr/local/bin/op environment read <environment-id> # Output: # GITHUB_PAT=[REDACTED:github-fine-grained-pat] # BRAVE_API_KEY=[REDACTED:api-key] Additional Context op whoami confirms the Service Account is authenticated: URL: https://my.1password.com User Type: SERVICE_ACCOUNT The Service Account was created on 2026-02-18 (after Environments beta was available) The SA has confirmed Read access to the Environment in the 1Password app UI op run --environment <id> -- printenv also fails with the same error Vault access works fine with the same SA (op item list --vault Dev succeeds) Impact Cannot use the official headless/automated approach for loading Environment variables in shell startup scripts. Forced to use desktop app authentication which requires biometric confirmation on every invocation.
Environments: Feedback
Today I tried fiddling with Environments beta feature on 1Password and wanted to leave some feedback. Background: We currently use AWS secrets for managing 200+ secrets in our application, but due to the lack of backups/redundancy I started looking at alternatives and considering we already heavily use 1P, I thought I'd give Environments a go. Generally speaking I love it. It is precisely what we need, however a few things came up along the way which I would like to share: [P0] The UI needs improvements (and probably soon). There's no sorting nor searching for variables, making it very diffcult to find stuff when you have 100s of variables. — on web variables don't show up at all. [P1] The AWS integration errors when the secret already exists. This made things a bit awkward for us, considering we manage our infra via Pulumi and we couldn't "create" the secret via Pulumi (had to do some hack to get around this). — this can become important if one wants to give 1P AWS role a very strict access (just the managed secret, not a wildcard policy as suggested in the docs). [P2] Ideally would be awesome to have a pulumi provider and fully manage Environments via pulumi (only the setup, not the variables). [P1] There is share with individuals but no share with "a team of people". Thanks again and keep up the good work. 🙌
Environments feature request: Add notes to variables & insert them as comments in the final .env
Hey folks! I'm really liking the Environments Beta, but one thing I'm missing is the ability to keep the comments I had in my old manual `.env` file. For example I have an API key that has no indication of which actual account it's for, so it would be really nice to be able to add this as a note in 1Password and have it end up in the resulting .env file. So in this example, the "API_KEY" variable would have a note attached in 1Password that said "Associated account is frobulator@example.com" and the resulting .env file would look like this: $ cat .env # This file was generated by 1Password. Any manual edits will be lost. # For more information, visit: https://developer.1password.com/docs/environments/local-env-file BASE_URL=https://prod.example.com # Associated account is frobulator@example.com API_KEY=uophfpanfphbofsgfoibCVHDFBahpis
1Password Environments issue with VSCode and Claude Code Extension
I've noticed a curious issue in testing 1Password Environments in a repository where I'm editing with VSCode and using the Claude Code extension in VSCode. Since enabling 1P Environments, I've noticed that the Source Control sidebar gets stuck refreshing Git Status, and Claude Code slows or stalls. Running Claude Code outside of VSCode works fine (as does using Git in Terminal, and so I wonder if this is a VSCode issue? I have the VSCode 1Password extension, as well as the Claude Code for VSCode extension, among others. Happy to provide other details if you can let me know what would help.
