cendarum export

cendarum export [--project <name|id>] --env <name|id> [--email <email>] \
                --scope shared|personal|effective \
                [--format dotenv|json] [--out <path>] [--force]

This is the one command that undoes the product

export writes your secrets in plaintext, outside every protection Cendarum provides. Once the file exists, it is a file: backed up, indexed by your editor, one git add -A from being published, and no longer covered by anything on the security pages.

Prefer cendarum run. It exists so that you almost never need this.

When you actually need it

One case: a tool that reads only a .env file and ignores its process environment entirely. Those are rare — most loaders read the environment first — but they exist, and pretending otherwise would just push people toward copy-pasting values by hand, which is worse.

If your tool reads the environment at all, use run.

It warns every time

Every invocation prints this to stderr, whether output goes to a file or a pipe:

cendarum: WARNING — this writes your secrets in PLAINTEXT, outside
Cendarum's zero-knowledge protection. Do not commit the result; delete it
when done. Prefer `cendarum run` (no plaintext ever touches disk).

There is no flag to silence it. A warning you can turn off is a warning that gets turned off in a shell profile and never seen again.

It refuses to write into a git working tree

$ cendarum export --env dev --scope shared --out .env.local
cendarum: error: refusing to write a plaintext .env inside a git working tree (use --force…)

The overwhelmingly common way a secret becomes public is being committed. If the destination is inside a repository, export stops. --force overrides it, and requires you to have read the sentence explaining what you’re overriding.

--force only applies together with --out; on its own it is a usage error, because there is nothing for it to force.

Which scope

--scope is required — an export names exactly what it emits, and a missing flag is refused before any password prompt or network call (cendarum: error: --scope <shared|personal|effective> is required, exit 2):

• shared — the team’s stream, without your overrides.
• personal — only your own personal overrides. No shared key or value appears.
• effective — exactly what run would inject: the shared values with your personal overrides composed on top. It prints the same value-free shadow-warning line run does, naming any personal key that shadows a shared one.

There is no default because the three files mean different things, and a merged default is how a personal secret ends up inside a .env you hand to a teammate. You name what you are writing, every time.

export --scope personal with no overlay refuses rather than falling through:

$ cendarum export --env production --scope personal
cendarum: error: no personal overrides exist for this environment (--scope personal)

An empty answer here is a vouched fact, and quietly serving the shared map instead would be a substitution — delivered by our own flag handling.

Flags

Flag	Meaning
--env <name|id>	Required. Source environment
--scope shared|personal|effective	Required. Which view to emit — see above
--project <name|id>	Disambiguates the environment name
--email <email>	Account email; falls back to CENDARUM_EMAIL, then a prompt
--format dotenv|json	Output format. Defaults to dotenv. Anything else is a usage error
--out <path>	Write to a file. Omitted, the payload goes to stdout
--force	Write inside a git working tree anyway. Requires --out

Afterwards

cendarum export --env dev --scope effective --out /tmp/app.env --force
run-the-awkward-tool --env-file /tmp/app.env
rm /tmp/app.env

effective is usually the scope you want here: the file gets exactly what run would have injected, personal overrides included.

Delete it. If you need it repeatedly, put the rm in the same script as the export so the cleanup can’t be forgotten — and add the path to .gitignore regardless, because --force only checks once and your future self will run it again from a different directory.