Skip to main content
Environment variables are workload input for the machine, and Capy never injects a value into its prompts or tool arguments. You set values in the app; Capy encrypts them at rest, injects them into the machine’s process environment at boot, and shows the agent only the variable names and whether each has a value. No tool, prompt, list API, or log carries a value, and no tool can set one. The limit: the machine is the agent’s execution environment, so code the agent runs can read anything on the machine, including your variables. Scope what you hand over accordingly.

The three scopes

Personal variables are for credentials that belong to you alone: your staging login, your API sandbox key. Thread variables are for handing a value to one running thread without publishing it to the project: the agent asks for a DATABASE_URL mid-run, you send it, it lands on the thread’s machines immediately. One caveat on personal values: a machine isn’t single-user. If you share a thread, whoever drives it can read your personal values on that machine, because they’re in the environment like everything else.

What the model sees, and what it can leak

  • The model sees variable names and configured-state. Values never enter the prompt, tool arguments, or anything Capy authors.
  • Values exist in plaintext exactly where they must: in your write request, briefly in Capy’s worker while assembling the machine’s environment file, and on the machine itself.
  • There is no output masking. The agent runs arbitrary commands, and a command that prints a value (printenv, a stack trace, a verbose CLI) puts that value into tool output, and tool output flows into the thread transcript like any other text.
So the real threat model is that any secret on the machine can end up in the transcript if a command prints it. Give the agent scoped, revocable credentials for the job at hand, not your production root keys.

How values reach a machine

Values are encrypted at rest (each value sealed under a KMS-managed key, bound to its exact project, scope, and name) and decrypted server-side only when a specific machine is being prepared. They’re written to a permission-restricted file outside your repository trees, excluded from diffs and snapshots, and sourced into every shell the agent runs, so test runners, SDKs, and arbitrary commands see them as ordinary environment variables. When values take effect:
  • Values are written when a machine boots. Editing a shared or personal value affects machines at their next boot; to get a value onto a running thread’s machines right now, send it through the composer’s environment variables dialog, which pushes immediately.
  • A running process keeps the environment it launched with until something restarts it.
Reading values back: the app reveals one value at a time to an authorized member (the eye toggle on the variables page). Lists show names and metadata only, and thread variables are write-only: you typed the value moments ago; resend it if needed.

Snapshots and scrubbing

Snapshot builds receive shared project values so your initialize script can authenticate private registries. Before capturing the image, Capy deletes the environment file and every platform-managed sensitive path, then verifies each one is gone. A build that can’t prove the scrub fails rather than baking a secret into a reusable image. What the scrub can’t prove absent is your own script’s behavior: an initialize that copies a value into a file in the workspace bakes that file into the snapshot. Keep secrets in variables; don’t write them to disk.

What never lands on a machine

  • GitHub credentials. Every git operation routes through Capy’s proxy, which injects credentials server-side; the machine holds only a bearer scoped to itself.
  • Capy’s own platform secrets (database, KMS, provider keys). The machine has no credential that can read any secret source.
  • Other tenants’ anything.
If you paste a provider token in as a plain project variable, that’s allowed: it’s a workload-input decision, and it travels with exactly the exposure this page describes.