Your data and credentials

The cloud machines in your project are full Linux machines. Files and credentials you put on them are available to the tools and coding agents running there, much as they would be on your development laptop. Before uploading files or connecting an account, choose credentials with the access you want that code to have. Prefer development, staging, sandbox, or read-only access when those credentials are enough for the work.

Files copied during setup

During local-folder setup, review the scan findings and setup bundle before approving the upload. Your selections can include:

• Repositories and Git metadata, submodules, and available Git LFS file contents.
• Staged, unstaged, and untracked files, plus selected Other project files.
• Environment and configuration files, database dumps, and setup artifacts.
• Local Codex and Claude history, if you include Agent threads.

You can edit the staged copy of an environment file in the setup editor to remove a secret before upload. That edit will not change the original file on your computer. boxes.dev will upload the staged copy.

Disposable agent worktrees are unchecked by default, as are repository folders offered as files-only copies. If you select a files-only copy, it will not include Git history.

If you choose SSH access, setup will copy the SSH keys you select. Setup will copy existing commit signing private keys only if you explicitly choose copy mode. Automatic GitHub access will install a credential helper without a stored token in the repository URL or a managed credential file.

The desktop app encrypts the staged bundle before upload. The setup job will decrypt it on your Template box so your development tools can use the files. Transfer encryption does not hide those files from code running on the machine. Local staging copies have owner-only permissions and remain in boxes.dev's local project setup records until those records are removed; deleting the project from the desktop app removes them.

During setup, review the selected files and configuration before they are copied. Select the image to enlarge it.

Agent and integration connections

Codex and Claude

Connect your own Codex or Claude account through the supported login or API-key flow. If access expires, use Configure agents. To remove a saved credential, open Configure agents, open the saved account or key's menu, and choose Remove; the confirmation will tell you whether another usable credential becomes active or the agent is disconnected. Removing a credential from boxes.dev doesn't invalidate it, so revoke or rotate it with the provider when you want existing access to stop. See Connect Codex and Claude for the full procedure.

Disconnecting integrations

Slack, Linear, and GitHub tokens are stored encrypted and used for the actions you enable. Slack and Linear are connected once for the whole team by a team admin; each member links or unlinks their own identity on the Account page. GitHub is connected by you for your own account. Disconnecting has these effects:

GitHub credentials on your machines

Automatic GitHub access and GitHub CLI in devboxes let tools on your machines request your connected GitHub credential. An App credential can grant access beyond the current project's selected repositories, but only where both your GitHub account and the boxes.dev GitHub App have permission. Code on the machine can read that token. Disconnecting will stop future issuance after a short cache period, but will not revoke an App token already held by a process.

If you also authorized personal access for repositories the App can't reach, that credential follows the GitHub CLI permissions you approved. Disconnecting personal access asks GitHub to revoke it, and disconnecting GitHub disconnects personal access too. Read Connect GitHub for token lifetimes and the separate Git and GitHub CLI controls.

AWS credentials on your machines

The AWS connection keeps your renewable sign-in encrypted in boxes.dev and supplies temporary credentials through the boxes-dev profile for your project's selected account and role. Removing AWS from one project will stop new credentials for that project; signing out everywhere will disconnect all your boxes.dev projects. Previously issued credentials can remain valid until their AWS expiry. Neither action changes your AWS account assignments or signs out other AWS browser sessions. For immediate revocation, use your organization's AWS controls. See Connect AWS.

Member files

A Team Template can require you to upload a personal configuration file, such as a CLI sign-in file, for your project. The admin defines a destination under Home or Project, but cannot inspect your file contents or information derived from them. The file can contain any bytes up to 256 KiB. Its original filename is used only in the upload view and is not saved by boxes.dev. For the requirement and upload flow, see Required member files and values.

Each saved file is encrypted for its exact project. Authorized boxes.dev services can decrypt it for delivery or a download you confirm with your account; this is not end-to-end or zero-knowledge encryption. Once delivered, the file is readable by the machine owner, root, processes, and coding agents.

To replace, remove, or download your saved file, open Project settings → Member files. Downloading requires recent confirmation with your linked Google account. Removing a required file will block future startup scripts and new Codex or Claude sessions until you provide a replacement; it will not stop an agent that is already running. Each machine will remove its managed copy the next time it syncs; a sleeping machine will do so after it wakes. Removal doesn't touch copies made elsewhere on the machine or revoke a credential a process has already read.

Editing or deleting the copy on the devbox will not change the centrally saved file. boxes.dev delivers the saved bytes when a devbox is created or wakes, when the saved file changes, and during periodic repair. That repair will replace local edits at the managed destination.

Later template changes depend on your project type: a Member project follows the Team Template's current file destinations, while an independent project created from a Team Template keeps the definitions it started with. If an admin changes the destination for your Member project, boxes.dev will remove the old managed file; choose Use my saved file at this new destination or upload a replacement before starting new work. Member files never go to Team Template editing machines or shared saved sources.

New parent directories have owner-only access, and delivered files are readable and writable only by their owner (mode 0600). Destinations must be relative paths under Home or Project; absolute paths, .., symbolic-link traversal, and directories are unsupported.

Machine isolation and sharing

Separate devboxes

Each devbox has its own files, processes, local databases, ports, and threads. Changes on one devbox do not automatically update other devboxes, your Template box, or a saved Team Template version; move changes between machines deliberately, with Git or another explicit workflow. In Member projects, prepared devboxes belong to one member and project. The team's startup script runs immediately before your project's script, with your prepared credentials and files available to both. Team admins are trusted authors of that code. A devbox assigned to your draft will not return to a pool or be reused for another member.

Several threads can run on one devbox and work in the same files. Different devboxes can also reach the same external service or database when they hold the same credential, and files you share through Shared project storage are available across the project's machines by design.

Files shared through a Team Template

Files that an admin deliberately leaves in a Team Template can be copied to projects and devboxes created from it, including .env files, databases, shell history, and manually installed credentials. Saving removes boxes.dev-managed private state, but does not identify secrets in team-authored files. If you administer a Team Template, review its files before saving and configure Template environment → Cleanup before saving when you need to remove additional data.

Public app access

Public links and Project URLs expose applications to people outside your account. Anyone with a public preview URL can access it until sharing stops. Stopping sharing will block new requests and close public WebSockets within 30 seconds. It will not erase downloaded or cached responses, and an HTTP response already in progress may finish. It will not stop the app or close another access path you have exposed. See Share a running app.

Stored history and diagnostics

Sign-in and account data

The desktop app and CLI may keep sign-in credentials on your computer so you do not have to sign in each time. When you sign up with a Google account whose email address Google does not manage, boxes.dev may ask for a six-digit email code to verify that address.

A Git author name and email saved in Account are also account data. They set the default identity on your ordinary machines; repository and user-authored Git settings can override them. They are not a credential or signing key and are not installed in Team Template admin checkouts or shared saved versions.

Files, conversations, and diagnostics

Most project files, terminal history, and session files live on the selected machine. boxes.dev also stores the project and machine metadata, thread history, activity, ports, notification tokens, and limited summaries and snippets used in the app. Saved thread history can be read without waking the machine.

Product analytics, crash reporting, and privacy-masked session replay help diagnose reliability and display problems. Native mobile replay masks standard text inputs before upload; ordinary displayed text, layout, movement, and interactions may remain visible. See the privacy policy for full disclosures and retention details.

Remove a credential supplied by mistake

If a secret reaches a machine by mistake, use its provider's controls to revoke or rotate it and invalidate any existing access. Then remove the copies: if the secret is a centrally saved member file, replace or remove it in Project settings → Member files. Delete ordinary copies from each machine and shared folder that received them. Cleaning one devbox doesn't clean other devboxes, your Template box, or an already saved snapshot or Team Template version; review those saved copies too.

Delete a devbox, project, or account

Save any files or work you need outside the machine or project before deleting it. Deletion is permanent.

Devboxes and projects

Destroying a devbox will permanently remove its own filesystem and archive its threads. Files in shared project storage live outside the devbox and remain until the project is deleted. Restoring an archived thread will restore the conversation, not the destroyed files.

Deleting a project will remove its personal Template box (if any), devboxes, snapshots, threads, shared project storage, and attached project data. Confirm project deletion by typing its name. Deleting a Member project will not delete the shared Team Template or affect another member's project. Deleting from the desktop app will also remove boxes.dev's local setup records for the project. Your original project folder on your computer will stay intact.

Your account

Account deletion is permanent. It will remove your account and sign-in records, settings and saved Git identity, owned project and machine data, SSH public keys, push tokens, telemetry, remote machines, snapshots, and their stored data. Team-owned Team Templates and other members' projects will remain.

To delete your account on the website:

1. Save any files or work you need outside boxes.dev.
2. Open Account and select Delete account….
3. Review the listed projects and their devbox counts.
4. Type DELETE, then select Delete to confirm.

You can also request account deletion from mobile Settings.

If you cannot sign in, email hi@boxes.dev from the account address with the subject “Delete my boxes.dev account.”

Report a security issue

Email security@boxes.dev with the affected part of the product, reproduction steps, impact, and a proof of concept if safe to share. Stop testing if you encounter sensitive data, and do not access, modify, or delete data that belongs to someone else.