Secrets

Secrets are environment variables (API keys, database URLs, service tokens) that OpenInspect injects into every sandbox launched from a scope, encrypted at rest and never shown again after you save them.

Scopes

Repository and environment secrets override a global secret with the same key. When you view a repository's secrets, inherited global keys appear in a read-only "Inherited from global scope" section with a Global badge, and a global entry that has been overridden shows which scope overrode it.

Global and repository secrets live under Settings › Secrets. Environment secrets live on the Secrets tab of each environment under Settings › Environments.

Which secrets a session receives

A session receives the global secrets plus the secrets of its session target, which is whatever you picked when you created the session.

Precedence, from the session target to the sandbox environment:

Environments are curated on purpose: a key added to a repository never silently lands in every environment that contains it. To reuse a repository secret in an environment, import it (below) or move it to global scope. The new-session picker states this when you select an environment or multiple repositories.

Adding secrets

Paste a .env file

Paste a .env-formatted block (KEY=value lines) into any input field. OpenInspect parses it and populates one row per key. Reserved keys in the pasted block are skipped and reported.

Update a secret

Existing values are masked (••••••••). To change a value, type the new value into the field and save. Leave the field empty to keep the current value.

Delete a secret

Click Delete next to the row and confirm.

Importing repository secrets into an environment

On an environment's Secrets tab, use "Import from a repository": pick a source repository that belongs to the environment, select the keys, and click Import. Values are copied server-side and never displayed.

Limits

If the merged payload for a session or an image build exceeds the combined cap, the spawn fails with an error that attributes bytes to each contributing scope so you know what to trim. This mostly matters for multi-repository sessions, where several repositories' secrets fold into one sandbox.

Reserved keys

These keys are used by the system and cannot be saved as secrets. The editor shows a validation error if you try.

PYTHONUNBUFFERED  SANDBOX_ID  CONTROL_PLANE_URL  SANDBOX_AUTH_TOKEN
REPO_OWNER  REPO_NAME  GITHUB_APP_TOKEN  SESSION_CONFIG
RESTORED_FROM_SNAPSHOT  OPENCODE_CONFIG_CONTENT
PATH  HOME  USER  SHELL  TERM  PWD  LANG

Security

• Values are encrypted with AES-256-GCM before they are stored.
• Values are never returned by the API after saving. Only key names are visible in the browser.
• Secrets are decrypted at sandbox creation time and injected as environment variables.
• System variables set by the control plane always take precedence over user-defined secrets with the same name.

Provider accounts are separate from secrets. OpenAI and xAI subscription credentials belong under Settings › Accounts, not in Secrets; their tokens stay in the control plane and are never injected into sandboxes. When a session runs in account mode, that provider's API key is removed from the sandbox environment so the runtime cannot bypass the selected subscription. API-key mode keeps using ordinary global, repository, or environment secrets. See provider accounts.

Secrets and prebuilt images

Image builds run .openinspect/setup.sh with the same secrets a session gets, so anything the script writes to disk is captured in the image and outlives a rotation. Read secrets from the environment at runtime instead. See Secrets and images for which secret changes trigger a rebuild.

Common examples

Troubleshooting

Next steps

• Environments
• Prebuilt images
• Provider accounts