You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow the schema filename to be something other than .env.schema — via an env var, a package.json field, or a config key.
Motivation
Coding agents are commonly sandboxed with a deny rule on .env* so they can't read secret-bearing dotenv files. That rule catches .env.schema too, even though it's committed and holds no values — so the agent can't read or edit the one file it's most useful for it to maintain.
Proposed Solution
No preference on mechanism.
Alternatives
Naming the real file .env-schema and symlinking .env.schema to it. Works, but the symlink has to be explained to everyone who sees it.
--path .env-schema also appears to work, but only applies to that one call site — anything else running varlock load sees no schema.
@theoephraim I think we'll need to think through how this works with the hierarchy of files that gets loaded, whether this replaces just the .env.schema (likely) or replaces a whole pattern?
If the .env is really the issue, we could potentially either allow swapping the default .env prefix for another, or even a suffix? Or could build in another separate suffix that we always automatically look for - something like *.envs (env-spec) or *.envv (env varlock)? Would likely just be confusing for many people though. It would also increase the number of files we are auto-detecting in many places, but should be fairly negligible.
Activity
pullfrog commentedon Aug 1, 2026
philmillman commentedon Aug 1, 2026
They typically respect
.gitignore, so usually a!.env.schemais enough but we will discuss, I've certainly been bitten by this many times.Thanks for the issue!
philmillman commentedon Aug 3, 2026
@theoephraim I think we'll need to think through how this works with the hierarchy of files that gets loaded, whether this replaces just the
.env.schema(likely) or replaces a whole pattern?theoephraim commentedon Sep 7, 2026
between
--pathand setting thevarlock.loadPathin a package.json, I feel like this is mostly handled?If the
.envis really the issue, we could potentially either allow swapping the default.envprefix for another, or even a suffix? Or could build in another separate suffix that we always automatically look for - something like*.envs(env-spec) or*.envv(env varlock)? Would likely just be confusing for many people though. It would also increase the number of files we are auto-detecting in many places, but should be fairly negligible.