#Environments & secrets

An environment is a named bundle of secrets — your API keys, tokens, and config values. Attach one to a chatspace and its values are injected as environment variables when the machine starts, so the agent (and your code) can use them.

Use them for things like a Vercel token, a Supabase service key, a database URL, or any KEY=VALUE your project needs.

#How it works

  • You create environments in the app and fill them with KEY=VALUE pairs.
  • Each chatspace is attached to one environment (you pick it when creating, or change it later).
  • When the chatspace starts, those values are decrypted and injected as environment variables into the agent's process. They're not written to disk on the machine.

Every account has a built-in Default environment. You can't rename or delete it, but you can put values in it.

#Creating and editing

In the app, go to your settings and open Environments:

  • Create a new environment with a name and a block of KEY=VALUE lines (standard .env format — blank lines and # comments are fine).
  • Edit an environment to add, change, or remove keys.
  • Switch which environment a chatspace uses — the change applies the next time it starts.

A few limits keep things sane: up to 100 keys, up to 8 KB per value, 32 KB total per environment. Keys must look like normal env-var names (letters, digits, underscores; not starting with a digit).

#Values are write-only

For safety, Chatspaces never shows you a secret's value again after you save it. The app shows your keys (with the value masked, like STRIPE_KEY ••••••), so you can see what's set and remove or replace keys — but the actual values only ever travel one way: in.

To change a value, just set the key again with the new value. To remove one, delete the key.

#Security

  • Secrets are encrypted at rest and decrypted only on our servers, at the moment a chatspace starts, to inject them.
  • They're not persisted to the machine's disk — they're passed straight into the agent's process environment.
  • Access is audit-logged, and secret-shaped values are scrubbed from logs.

See Provider credentials for the same protections applied to your Claude and Codex logins.

#Special case: GITHUB_TOKEN

If you set a key named GITHUB_TOKEN in an environment, it overrides the GitHub access Chatspaces would otherwise manage for that chatspace — git and the gh CLI will use your token instead. This is the way to bring your own GitHub Personal Access Token. See GitHub access for when you'd want this.

Note

Setting GITHUB_TOKEN to an empty value disables the managed token without supplying a replacement — useful if you want a chatspace with no GitHub write access at all.

#Opting out of an environment

A chatspace doesn't have to use any environment. If you set it to none, no secrets are injected — the chatspace still works, but anything that needs those keys (deploys, external APIs) won't have them.

Heads up

If you delete an environment that a chatspace is using, that chatspace is left with no environment (it doesn't silently fall back to Default). Pick a new one before you next start it.

Next: how GitHub access is scoped, or how usage is measured.

← Previous Live preview links Next → GitHub access