Read access is set per environment. A readable environment can be pulled into a local .env; a run-only environment can only be used through vexly run, where its secrets are injected into a process but never downloaded or printed. Run-only is what lets an agent run your app with real secrets without ever reading them.

How it works

Each environment has one of two access modes:

• Readable (default) — vexly pull downloads the environment’s secrets into your local .env, and vexly ls --reveal can print them. You (or an agent) can read the values. This is the normal solo-dev flow.
• Run-only — the secrets can only be consumed through vexly run, which injects them straight into the launched process. vexly pull and any plaintext export are refused for that environment, with a clear message.

The CLI surface is the same either way — the same pull and run commands exist. The environment’s mode decides what succeeds, enforced by the server. A typical setup keeps development readable and production run-only.

Access mode is set in Studio, not the CLI. Because Studio is for claimed projects, run-only applies to claimed projects only — anonymous projects are always readable. To hand an agent run-only access, first claim the project, then set the environment to run-only in Studio.

Access mode is one of two independent settings on an environment; the other is visibility (private vs. anonymous access). Mode controls what you can do — read vs. run; visibility controls who can do it.

What run-only does and doesn’t protect

Run-only is an anti-leak guarantee, not a hard security boundary. Its everyday value is keeping secrets out of an agent’s context — its chat transcript, command output, logs, or a .env on disk. With a readable environment an agent could pull the secrets and might read or print them; with a run-only environment it must use vexly run, which injects the values straight into your app’s process, where the agent never sees them.

• Secrets aren’t written to .env, printed, or surfaced into an agent’s chat in normal use.
• It is not a wall against a hostile actor who controls the machine. Anyone allowed to run chooses what command to run (vexly run -- printenv would dump the values), and a malicious process on a machine where you’re logged in could read your session and act as you.

The real guarantee comes from isolation, not a toggle. To truly stop an untrusted agent from reaching beyond one run-only environment, run it where your full login isn’t present — a container, CI job, or separate account with only a scoped VEXLY_TOKEN. Then there’s no broader credential to take.

So read run-only as “my secrets don’t show up in the agent’s view during normal work,” not “a hostile process can never read them.” For the dominant case — a trusted agent (such as Claude Code) on your own logged-in machine — that context-hygiene is exactly the point, and the main reason run-only exists.

Commands

Next

• Running commands — how run injects secrets.
• Agent & CI access — scoped tokens and run-only agents.
• Projects & access — claiming and visibility.