> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Environment variables

> Environment variables CoreWeave sets inside every sandbox, and how to override them.

This page describes the environment variables CoreWeave sets inside every sandbox, and how to read them from code running in the sandbox. The platform sets them at creation time, in addition to any variables you supply yourself, so that your code can identify its own runtime.

To set your own variables, see [Set your own environment variables](/products/sandboxes/client/guides/environment-variables).

<Note>
  CoreWeave sandboxes are in public preview. For access, contact your CoreWeave account team, [CoreWeave Support](https://cloud.coreweave.com/contact), or email [support@coreweave.com](mailto:support@coreweave.com).
</Note>

## Variables

The platform sets the following variable in every sandbox:

| Variable        | Value | Description                                                                                                                                      |
| --------------- | ----- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| `CW_SANDBOX_ID` | UUID  | The sandbox's own ID. Identical to the ID returned when the sandbox is created, and the ID you use in API and SDK calls that act on the sandbox. |

The platform sets these variables regardless of which SDK or API version you use.

<Note>
  Don't parse the hostname to obtain the sandbox ID. A sandbox's hostname begins with the sandbox ID, but it carries a generated suffix that changes if the underlying pod restarts. Use `CW_SANDBOX_ID` instead.
</Note>

## Read a variable

Platform variables are available to each container's main process, to any process it starts, and to processes started with `exec` and streaming execution. The exception is a program that clears its environment before starting a child.

<Tabs>
  <Tab title="Python">
    ```python theme={"system"}
    import os

    sandbox_id = os.environ["CW_SANDBOX_ID"]
    print(f"running in sandbox {sandbox_id}")
    ```
  </Tab>

  <Tab title="TypeScript">
    ```typescript theme={"system"}
    const sandboxId = process.env.CW_SANDBOX_ID;

    console.log(`running in sandbox ${sandboxId}`);
    ```
  </Tab>

  <Tab title="Shell">
    ```bash theme={"system"}
    echo "$CW_SANDBOX_ID"
    ```
  </Tab>
</Tabs>

A common use is tagging logs or metrics emitted from inside the sandbox, so that you can later correlate records with the sandbox that produced them.

## Override a variable

Platform variables are defaults, not reserved names. If you set a variable of the same name on your sandbox, the sandbox uses your value and the platform does not apply its default.

Replace `[YOUR-VALUE]` with the value you want the sandbox to report:

<Tabs>
  <Tab title="Python">
    ```python theme={"system"}
    from cwsandbox import Sandbox

    sandbox = Sandbox.run(
        container_image="ubuntu:22.04",
        environment_variables={"CW_SANDBOX_ID": "[YOUR-VALUE]"},
    )
    ```
  </Tab>

  <Tab title="TypeScript">
    ```typescript theme={"system"}
    import { createSandboxClientFromEnv } from "@coreweave/cwsandbox/node";

    const client = createSandboxClientFromEnv();

    const sandbox = await client.create({
      containerImage: "ubuntu:22.04",
      environmentVariables: { CW_SANDBOX_ID: "[YOUR-VALUE]" },
    });
    ```
  </Tab>
</Tabs>

The following rules apply to overrides:

* **Any value counts, including an empty string.** Setting `CW_SANDBOX_ID` to `""` produces a variable that is present and empty. The platform does not treat an empty value as unset and does not replace it.
* **Secrets count as overrides.** A [secret](/products/sandboxes/client/guides/sandbox-configuration#secrets) mapped to the same variable name suppresses the platform default in the same way a direct value does.
* **A policy cannot override platform variables.** The name is reserved against operator configuration, so a cluster's [policy](/products/sandboxes/profiles/configure) cannot silently replace a value you set.

## Metadata only, not identity

`CW_SANDBOX_ID` is advisory metadata. Because it can be overridden, code inside a sandbox can report any value.

<Warning>
  Do not use `CW_SANDBOX_ID` for authentication, authorization, or audit attribution. Your own systems recorded a sandbox ID when they created the sandbox. Treat that ID as the source of truth, not a value reported from inside the sandbox.
</Warning>

## Sandboxes with more than one container

Each container receives the value set on the sandbox's first container, unless that container sets `CW_SANDBOX_ID` itself. An explicit value takes precedence for the container that sets it.

This has two consequences:

* If you override the variable on the first container, every other container that sets nothing receives your override.
* If you override it to an empty string on the first container, the other containers do not receive the variable at all.

## Behavior across the sandbox lifecycle

`CW_SANDBOX_ID` behaves as follows across a sandbox's lifetime:

* **The value is fixed for the life of the sandbox.** The platform assigns it at creation, and it does not change if the underlying pod restarts.
* **A restored sandbox is a new sandbox.** Restoring from a file system snapshot creates a sandbox with a new ID, and `CW_SANDBOX_ID` carries that new value. Any earlier ID your application wrote into a snapshot volume persists as your own data and is not updated.