Most of the time an agent needs no setup: anonymous projects need no auth, and an agent on your own machine reuses your vexly login. You only set a token for headless or CI runs, or to give an agent access scoped differently from your own — typically run-only.

How credentials resolve

A non-interactive caller — the CLI in CI, or an agent driving the CLI — resolves credentials in this order:

1. Anonymous — no credential. Anonymous projects need no auth at all. An agent can create and work with one with nothing configured. This is the zero-friction default.
2. Your existing login. On a machine where you’ve run vexly login, that session is reused automatically — including by a local agent running the CLI. Nothing to create.
3. VEXLY_TOKEN. A token set explicitly, used when there’s no login session (headless or CI) or when an agent needs scoped access. It takes precedence over the stored login.

So you only mint a token when (1) and (2) don’t apply: true headless/CI, or scoped run-only access. Tokens are created and revoked in Studio — the CLI only ever consumes them.

Run-only agents on your own machine

The common case — a trusted agent such as Claude Code on a machine where you’re already logged in — needs no extra setup:

1. Once: set the sensitive environment (e.g. production) to run-only in Studio.
2. The agent runs vexly run -- <your app>. Because the environment is run-only, vexly pull is refused, so the agent uses run — which injects the secrets into your app’s process, where they’re never written to .env or shown.

You stay logged in and the agent has your access, but your secrets don’t show up in its context. That context-hygiene — not a hard wall — is the point. To actually contain an untrusted agent, run it where your login isn’t present (a CI job or container with only a scoped VEXLY_TOKEN).

CI pipelines

Set VEXLY_TOKEN in your CI secrets, then run your build or deploy command through Vexly:

vexly run -- npm run build      # secrets injected, never written to disk
vexly run -- ./deploy.sh

On a readable environment you can also vexly pull to materialize a .env if a step needs the file. On a run-only environment, use vexly run.

Token scope

A token is scoped to a single environment, so a leaked agent or CI token can’t reach your other environments. The environment’s access mode governs what the token can do: a token for a run-only environment can only run; a token for a readable environment can also pull.

Commands

Next

• Access modes — what run-only does and doesn’t protect.
• Running commands — vexly run in detail.
• Projects & access — login, claiming, and workspaces.