I’ve been thinking through a CLI design problem around team .env workflows.

The target workflow is:

git clone repo
login
pull

The question is:

How should a CLI know which secret vault belongs to a cloned repo without requiring the developer to paste a vault ID, and without committing actual secrets to Git?

One approach is to commit a small project metadata file:

# .meowpass.yaml
version: 1
vault: <vault_id>
default_env: development

This file contains no secret values. It only maps the repo to a remote vault and default environment.

The CLI resolution order would be:

1. explicit --vault flag
2. nearest .meowpass.yaml, found by walking up parent directories
3. global user config
4. fail with a fix-oriented error

This makes the CLI behave more like Git.

Example:

repo/
  .meowpass.yaml
  apps/web/
  packages/api/

If you run the CLI from apps/web, it still resolves the project config from the repo root.

Some design choices I’m considering:

• The project config is safe to commit because it contains metadata only
• Explicit flags always override project config
• version allows schema migration later
• default_env makes common commands deterministic without extra flags
• Diff output should show changed/missing keys, but never reveal values

Example diff output:

Local only:
- DEBUG_TOKEN

Remote only:
- STRIPE_SECRET_KEY

Changed:
- DATABASE_URL

The tradeoff is that this is less local-first than committing encrypted .env files to Git, but it improves onboarding because the repo can point to the correct vault without embedding secrets.

The model is basically:

repo metadata in Git
secret values outside Git
CLI resolves project context automatically

Questions I’m still debating:

• Should default_env live in repo config, or should it stay local per developer?
• Should parent directory discovery stop at the Git root?
• Should the CLI warn if suspicious keys like API_KEY or DATABASE_URL appear in the config file?
• Is committing a vault ID acceptable if auth and encryption still gate access?
• Is this better or worse than committing encrypted .env files?

Curious how others would design this.

For team secret sync, would you use a committed metadata file, encrypted env files in Git, or another approach entirely?