Skip to content

Bug: python-dotenv doesn't load 1Password “mounted” .env files (looks like a FIFO / fd-backed file) #598

Description

@lukeocodes

I’ve been trying 1Password’s new environment feature which mounts a .env file to a destination path (I think it’s a pipe, file descriptor path, or some other non-regular file). This seems to be a Mac feature right now.

python-dotenv doesn’t seem to load anything from it, even though the path exists.

What I expected

load_dotenv() (or dotenv_values()) should read key/value pairs from the mounted .env file, same as a normal file. I'd expect something similar to Node's dotenv package, that when the file tries to be read, 1Password prompts you to allow access. Only then are the values available

What happened instead

The file path exists, but reading it gives an empty string (and python-dotenv ends up loading nothing).

Quick sanity check:

from pathlib import Path

p = Path(".env")
print("exists:", p.exists())
print("readable:", p.read_text(errors="replace"))

Output:

exists: True
readable:

Repro steps

  1. Use 1Password to mount / expose a .env file (however their new environment feature does it).
  2. Point the app at that .env path (eg in the project root as .env).
  3. Call load_dotenv() or dotenv_values().
  4. Observe that nothing is loaded.

Versions

  • OS: macOS 15.6
  • Python: 3.13
  • python-dotenv: 1.0.1
  • 1Password + CLI: 8.11.22

Activity

  1. Aakash0440 commented on Jan 24, 2026

    @Aakash0440

    This looks like python-dotenv assuming a regular file, whereas 1Password mounts a FIFO / fd-backed file.
    I’m happy to investigate adding support for non-regular files by falling back to streaming reads instead of relying on file size or seekability.
    I’ll also look into adding a test using a FIFO to simulate this behavior. Let me know if that approach sounds reasonable.

  2. lukeocodes commented on Jan 26, 2026

    @lukeocodes
    Author

    This looks like python-dotenv assuming a regular file, whereas 1Password mounts a FIFO / fd-backed file.
    I’m happy to investigate adding support for non-regular files by falling back to streaming reads instead of relying on file size or seekability.
    I’ll also look into adding a test using a FIFO to simulate this behavior. Let me know if that approach sounds reasonable.

    Did you check the already referenced PR?

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions