> ## 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.

# 환경 변수

> CoreWeave가 모든 샌드박스에 설정하는 환경 변수와 이를 재정의하는 방법을 알아봅니다.

<Note>
  The examples on this page omit `auth`. To authenticate with your W\&B API key, install `cwsandbox[wandb]` and pass `auth=AuthStrategy.WANDB` to `Sandbox.run()`, `Sandbox()`, or `Sandbox.session()`. See [Get started](/products/sandboxes/serverless/get-started).
</Note>

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](client/guides/environment-variables).

## 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.

- **시크릿도 재정의로 간주됩니다.** 같은 변수 이름에 매핑된 [시크릿](/ko/products/sandboxes/serverless/secrets)은 값을 직접 지정할 때와 마찬가지로 플랫폼 기본값이 적용되지 않도록 합니다.

## 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.