---
title: Built-in Properties
url: /docs/esc/concepts/builtin-properties/
---


Besides the properties defined within an environment, [references](/docs/esc/concepts/interpolations-and-references/) can access three built-in properties: information about the user evaluating an environment (`context`), other environments in the organization (`environments`), and imported environments (`imports`).

## context

The `context` built-in property provides information about the environment being evaluated, the user requesting it, and the access token they used.

  
  

<link rel="stylesheet" href="/fingerprinted/css/openapi.8a391e08d10f578bfba39cc7de95ddd7b9f56cee93f2dbab4f2e84f0c72bd369.css">

`context.currentEnvironment.name`
string

The name of the environment currently being evaluated — the one the reference itself is written in — as `<project>/<name>`. Inside an imported environment it is the import exactly as written in the importing environment’s `imports:` list, so an import written `payments/db` resolves to `payments/db`. Environments in the legacy `default` project may be imported without a project prefix; those resolve as written too, so `db` stays `db` and `default/db` stays `default/db`.

`context.pulumi.openDuration`
string

How long the opened environment’s values remain valid, as a [Go duration](https://pkg.go.dev/time#ParseDuration) string such as `2h0m0s`. This reflects the lifetime requested for this particular open, so the same environment can evaluate it differently from one open to the next: `pulumi env open <environment> --lifetime 30m` resolves it to `30m0s`, and opening without a lifetime resolves it to the default of `2h0m0s`.

`context.pulumi.organization.login`
string

The login of the organization that owns the environment being opened. This is the organization’s URL slug, not its display name: an organization displayed as “Acme Corp” resolves to `acme-corp`.

`context.pulumi.token.name`
string

The token’s name. Empty for personal and web tokens.

`context.pulumi.token.team`
string

The name of the team a team-scoped token belongs to. Empty for tokens that aren’t team-scoped.

`context.pulumi.token.type`
string

The type of the access token used to open the environment, such as `personal`, `team`, or `organization`.

`context.pulumi.user.login`
string

The login of the requesting user. For a team or organization token this resolves to the organization’s name rather than an individual, so it does not on its own identify who is calling — use `pulumi.token.type` and `pulumi.token.team` to tell those callers apart.

`context.rootEnvironment.name`
string

The name of the environment the caller opened directly, as `<project>/<name>`. It is fixed for the whole evaluation, so a reference in an imported environment still resolves it to the environment that started the evaluation rather than to the import: opening `payments/prod` resolves it to `payments/prod` throughout. Environments in the legacy `default` project are the exception — the prefix is stripped, so opening `default/prod` resolves it to `prod`.

  

For a worked example of how `currentEnvironment.name` and `rootEnvironment.name` differ inside an imported environment, see [How attributes resolve across imported environments](/docs/esc/guides/configuring-oidc/#how-attributes-resolve-across-imported-environments).

```yaml
values:
  greeting: Hello, ${context.pulumi.organization.login}/${context.pulumi.user.login}!
```

### Differentiating callers by token

For team and organization tokens, both `user.login` and `organization.login` resolve to the organization name, so neither one distinguishes a team token from an individual user. The `context.pulumi.token` properties are the way to tell those callers apart:

```yaml
values:
  callerType: ${context.pulumi.token.type}
  callerTeam: ${context.pulumi.token.team}
```

`token.type` and `token.team` are also available as OIDC subject attributes, which lets a cloud provider's trust policy scope an assumable role to a specific team. `token.name` is deliberately excluded from subject claims because token names are chosen by the user and could be crafted to forge a subject. See [Custom token claim](/docs/esc/guides/configuring-oidc/#custom-token-claim).

## environments

The `environments` built-in property provides access to other environments within the same organization. This allows the selective use of values from other environments without explicitly importing them. Reference a value as `${environments.<project>.<environment>.<property-path>}`.

```yaml
values:
  other: Hello, ${environments.app.dev.name}!
```

## imports

The `imports` built-in property provides access to imported environments, including those that are imported without participating in the merge stack (`merge: false`). For details on importing environments, see [Imports](/docs/esc/concepts/imports/).

```yaml
imports:
  - app/dev: { merge: false }
values:
  other: Hello, ${imports["app/dev"].name}!
```