{"meta":{"title":"Persisting environment variables and temporary files","intro":"You can configure custom environment variables so that they are set to the same value every time you open a codespace. You can also ensure that temporary files are not deleted when a codespace stops.","product":"Codespaces","breadcrumbs":[{"href":"/en/codespaces","title":"Codespaces"},{"href":"/en/codespaces/developing-in-a-codespace","title":"Developing in a codespace"},{"href":"/en/codespaces/developing-in-a-codespace/persisting-environment-variables-and-temporary-files","title":"Persist variables and files"}],"documentType":"article"},"body":"# Persisting environment variables and temporary files\n\nYou can configure custom environment variables so that they are set to the same value every time you open a codespace. You can also ensure that temporary files are not deleted when a codespace stops.\n\n## Setting persistent environment variables\n\nYou can set persistent custom environment variables in multiple ways, depending on which codespaces, repositories, or users you want the variables to be available to.\n\nFor all the methods of setting custom variables listed below, you can access the custom variable in your codespace by using syntax like `echo $VARNAME`.\n\n### For a single codespace\n\nYou can set the value of the environment variable in the `~/.bashrc` file, or in an equivalent configuration file if you are not using the Bash shell. For example, add the statement `VARNAME=value`.\n\nAfter you save the change to this file, the value will be set the next time you open the codespace, or you can set it immediately by using a command such as `source ~/.bashrc`. The variable will remain set if you stop and start the codespace. However, changes to files in the home directory will be reset if you rebuild the container, so variables set in the `~/.bashrc` file will not persist over a rebuild. For more information, see [Preventing temporary files from being automatically deleted](#preventing-temporary-files-from-being-automatically-deleted).\n\n### For all codespaces for a repository\n\nThere are three ways that you can set persistent custom environment variables for all codespaces that you create for a repository:\n\n* You can edit the `devcontainer.json` configuration file for the repository.\n* You can use a custom Dockerfile.\n* You can use development environment secrets.\n\n#### Edit the `devcontainer.json` configuration file for the repository\n\nEdit the `devcontainer.json` configuration file for the repository, and use the `remoteEnv` property to set the environment variable value:\n\n```json\n{\n  \"remoteEnv\": {\n    \"VARNAME\": \"value\"\n  }\n}\n```\n\nOnly use this method for values that you are happy to commit to your repository as plaintext. For sensitive values such as access tokens, use development environment secrets.\n\nThe environment variable will be set within your editor's remote server process, and will be available for sub-processes of that remote server process, such as terminals and debugging sessions. However, the variable will not be available more broadly inside the container. This method is useful if you don't need the environment variable to be set for other background processes that run at startup, and if you are using a premade image and don't have or want a custom Dockerfile.\n\nThis setting will take effect when you rebuild your container or create a new codespace after pushing this change to the repository. For more information about applying configuration changes to a codespace, see [Introduction to dev containers](/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers).\n\n#### Use a custom Dockerfile\n\nIf you are using a custom Dockerfile you can set the environment variable there by adding `ENV VARNAME=value`.\n\nThis method is useful if you already have a Dockerfile and want to set a variable on a container-wide level.\n\nThis setting will take effect when you rebuild your container or create a new codespace after pushing this change to the repository. For more information about applying configuration changes to a codespace, see [Introduction to dev containers](/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers).\n\n#### Use development environment secrets\n\nYou can use development environment secrets for GitHub Codespaces to set custom variables for codespaces created for the repository. For more information, see [Managing your account-specific secrets for GitHub Codespaces](/en/codespaces/managing-your-codespaces/managing-your-account-specific-secrets-for-github-codespaces).\n\nYou should use this method for environment variable values that you do not want to commit to the repository as plaintext.\n\nThis setting will take effect the next time you create a codespace for this repository, or when you restart an existing codespace.\n\n### For all codespaces that you create\n\nIf you want to set a personalized environment variable for all codespaces that you create you can set this using a file in your `dotfiles` repository. For example, add `VARNAME=value` in the `.bash_profile` file. Environment variables you set in a dotfile are personal to you and are not set for anyone else. For more information about Dotfiles, see [Personalizing GitHub Codespaces for your account](/en/codespaces/setting-your-user-preferences/personalizing-github-codespaces-for-your-account#dotfiles).\n\n## Preventing temporary files from being automatically deleted\n\nWhen you create a codespace, your repository is cloned into the `/workspaces` directory in your codespace. This is a persistent directory that is mounted into the container. Any changes you make inside this directory, including editing, adding, or deleting files, are preserved when you stop and start the codespace, and when you rebuild the container in the codespace.\n\nOutside the `/workspaces` directory, your codespace contains a Linux directory structure that varies depending on the dev container image used to build your codespace. You can add files or make changes to files outside the `/workspaces` directory. For example, you can install new programs, or you can set up your shell configuration in a file such as `~/.bashrc`. As a non-root user, you may not automatically have write access to certain directories, but most images allow root access to these directories with the `sudo` command.\n\nOutside `/workspaces`, with the exception of the `/tmp` directory, the directories in a codespace are tied to the lifecycle of the container. This means any changes you make are preserved when you stop and start your codespace, but are not preserved when you rebuild the container. For information about creating symlinks to preserve data outside the `/workspaces` directory, see [Rebuilding the container in a codespace](/en/codespaces/developing-in-a-codespace/rebuilding-the-container-in-a-codespace#persisting-data-over-a-rebuild).\n\nThe `/tmp` directory is an exception because it is mounted into the container, but it is not persistent. Therefore, the contents of the `/tmp` directory are persisted over a rebuild, but are cleared each time the codespace stops. For example, the `/tmp` directory is cleared when a codespace session times out after a period of inactivity. For more information, see [Setting your timeout period for GitHub Codespaces](/en/codespaces/setting-your-user-preferences/setting-your-timeout-period-for-github-codespaces).\n\nIf you have temporary files that you want to be available the next time you start the codespace, do not save them in the `/tmp` directory.\n\n## Further reading\n\n* [Changing the shell in a codespace](/en/codespaces/customizing-your-codespace/changing-the-shell-in-a-codespace)"}