Security and data

Security explains where your data lives and what an agent and devboxes in Chat can reach.

Your credentials

devboxes stores these encrypted and never shows them again:

• model provider keys,
• repository access tokens,
• secrets, and
• chat and tracker tokens.

Variables are not secret. Anyone in the Organization can read them. Put tokens and passwords in secrets.

devboxes keeps the values of secrets in Infisical, a secrets manager that devboxes runs on its own servers in Germany. The devboxes database holds their names and the Projects they belong to. Deleting the Organization deletes its secrets in Infisical too.

Secrets in what a Session sends back

devboxes removes your secrets from what a Session sends back. When an agent's output, a command result, a review finding, or a capability call contains the value of one of the Project's unprotected secrets, or of its model account's key or tokens, devboxes replaces that value with [redacted] before the Session sends it. This covers Session events, results, and checkpoints. devboxes also replaces the value when it is JSON-escaped or URL-encoded and, for values of 8 or more characters, when it is hex or base64 encoded, even across wrapped lines. Tokens with a known format, such as GitHub, Slack, and OpenAI keys, private keys, and JWTs, are removed the same way, even when they aren't one of your secrets.

Redaction works on text only. Files the agent writes, its commits and pushes, workspace archives, and artifacts are kept exactly as they are, so a secret the agent writes into a file stays in that file. A value split across several outputs, or changed in some other way, can get through. Your model provider sees everything the agent sees.

devboxes' own server logs and error reports remove devboxes' own credentials, also when they appear base64, hex, or URL encoded, and tokens of well-known formats, such as GitHub, Linear, and npm tokens, devboxes tokens, and private keys.

Who can see what

• Members of an Organization can see its Sessions and what the agents did.
• A delegation token can do only what you listed when you created it, and only what your role allows.
• A delegation token without an expiry works until you revoke it. See delegations.
• An owner can see every member's delegations and revoke any of them without removing the member.
• People in a connected Chat channel can start tasks in the channel's Projects, even when they are not members. See Chat.

Roles

Owners and admins add or replace credentials: model accounts, repository connections, Chat and tracker connections, Runners, and secrets. They set variables too, because a variable can hold a credential or take a secret's name. That holds for delegation tokens too. Chat can't add or replace a credential. Every member's tasks use the credentials an owner or admin added.

Every role can write, commit, bind, and archive Blueprints. A sensitive integration, such as writing to GitHub pull requests, needs an owner. A task that reaches it starts only with a Blueprint version that an owner approved, whoever starts it, and a task calls a sensitive operation only while its version is approved, even one an owner marked while the task ran. Outside a task, only an owner calls a sensitive operation: from the CLI or the API, or in Chat from a chat account linked to them. Only owners mark integrations sensitive and approve versions. An Organization always keeps at least one owner.

Configuration that OpenCode reads

OpenCode runs the agent and reads its configuration from these places:

The agent can write to the repository during the Run. devboxes ignores these items in every location, including in files that the agent writes:

• plugins entries,
• files in plugins/ and plugin/ folders,
• providers entries, and
• {file:...} references, which stay literal text.

The model account that the Run uses decides the model provider.

End access

What an agent already pushed or posted stays where it is.

connections.delete refuses while a Project or the Chat policy selects the model account, or while queued or running work uses it. To stop a leaked key at once, replace it with connections.update, which takes effect for the next model request, and revoke the old key with your model provider. Then move the Projects and the Chat policy to another account and delete this one.

Erase data

Owners and admins erase Sessions, conversations and any message. Every member erases Organization memory entries and the messages they wrote. In Chat, anyone talking with devboxes in a thread can have it erase messages of that thread's channel. Erasing removes the data from devboxes. devboxes also erases a Session itself once its last activity is older than your plan keeps history. Branches, pull requests, issues, and chat messages in your other tools stay. A Session's branch name contains a short form of the Session's title, so that text stays in your repository after you erase the Session.

No command erases a Person or a Persona. A Person deletes their own preferences with people.forget. Erase data says how to have them removed. To stop a Persona from shaping how devboxes answers, deactivate it. See Personas.

Erase an Organization memory entry

Erasing an entry removes its text from Organization memory. Its index, author, source and date stay. The conversation where someone said it can still hold the entry's text in its messages. To remove that text, erase those messages.

Erase Chat messages

Erasing a message removes its text from devboxes:

• from the Chat log, which also forgets who wrote it. Its place, kind and time stay, with the chat's own message ID, so devboxes never logs the message again when it reads the thread;
• from every summary that read it, which devboxes writes again without it;
• from the record of the reply that answered it, or that it is. That record keeps who asked, which devboxes needs to check what they may do and to show what happened;
• from the Organization memory entries it saved, which are erased with it;
• in Telegram, from the recent messages that devboxes keeps of the chat.

A message that devboxes still needs for a reply it hasn't posted can't be erased until that reply is posted. Erasing a message doesn't delete it from your chat app: the people there delete their own posts, and devboxes' replies stay in the thread.

Erase a Chat conversation

Erasing a conversation removes it and its messages from devboxes, including every Chat log that holds them, where devboxes keeps the messages of a channel's threads in order. From then on, Chat no longer shows or continues any Session in which the conversation started work, in any channel. The Sessions themselves stay, and the CLI and the API still show them. Erase a Chat conversation shows how to erase that work first.

A direct conversation starts no Sessions and adds no Organization memory entries, so you can erase it without these steps. Only its Person can inspect it.

A conversation erasure keeps:

• The Sessions in which it started work, until you erase them or your plan's history ends. Chat no longer shows them.
• The Organization memory entries it added, until you erase them.
• Preferences a Person stored from their direct conversation with people.remember or people.correct, until they delete them with people.forget.
• In its channel's Chat log, the place of each of its messages: what kind of message it was and when devboxes logged it, with no text and no ID of who wrote it.
• Records of replies that devboxes rewrote before posting. They keep the turn's ID without its text and expire after 180 days.
• For 24 hours after a message arrives, the IDs that devboxes uses to ignore a repeated delivery: the chat message ID and, in Slack, the event ID.
• In Slack, for 1 hour after Slack adds link previews to a message: the links' URLs, titles, and preview text, stored under the channel and message IDs.
• In Microsoft Teams, the message ID of a reply that was being posted while you erased. It expires after 7 days.
• In Slack and Microsoft Teams, what devboxes recorded from a message sent in the thread between the erasure's cleanup and its final delete: the sender's Slack user ID for 8 days, or the Teams reply address.

Copies that erasing can't reach at once

• Traces. devboxes keeps traces of its replies, summaries and tasks in its own Langfuse. Since 2026-10-14 they hold what the model answered, not what people wrote. Traces from before keep what people wrote until they expire, around mid-November 2026.
  • Erasing a message deletes the trace of the turn that answered it and of the summaries that read it.
  • Erasing a conversation deletes the traces of its turns, and erasing a Session the traces of its tasks.
  • Langfuse deletes them in the background. If Langfuse refuses, devboxes tries again for about four days.
  • A summary that devboxes started but didn't keep, because an erasure or another attempt overtook it, keeps its trace until traces expire after 30 days.
• Messages that quote it. Another reply or message that quoted the erased text keeps it until you erase that one too, and so do its trace and the summaries that read it. A waiting request or a Schedule keeps the words it was given until it is withdrawn or deleted.
• Model providers. A provider can keep a request in its prompt cache until the cache expires: on Anthropic, after 5 minutes or 1 hour, and on OpenAI and Codex, after up to about 90 minutes. devboxes doesn't send the erased message to a model again. Each provider also keeps requests as its own data policy says: the OpenAI API keeps them for up to 30 days unless your account has zero data retention.
• Backups. devboxes' database backups keep erased data until they expire, at most about 37 days after the erasure.