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

# Production safeguards and approvals

> How a target’s environment is classified, why production access is gated, and the reason/approval flow members must follow.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Get production terminal, command, and runbook access without being surprised by reason requirements or approval gates.

## Prerequisites

* Understand access and permissions first

## Workflow

<Steps>
  <Step>
    Each target carries an environment derived from the project’s environment setting.
  </Step>

  <Step>
    If the project environment is unset, the target is treated as production by default.
  </Step>

  <Step>
    Production access requires the production session permission; a member without it must request approval.
  </Step>

  <Step>
    Production sessions, one-off commands, and runbooks require a written reason between 10 and 500 characters.
  </Step>
</Steps>

## Environment classification (important)

A target is production when the project’s environment is "production" — and when the environment is left unset, it defaults to production. This means a project with no explicit environment value gates every team member out of app shells until they are granted production access, set the environment to staging/development, or go through approval. Owners and admins are not blocked because they already hold the production session permission.

## The approval flow

* A member requests approval for a specific target and mode, with a reason (10–500 characters).
* A user with terminal.approve\_production reviews and approves or denies it; requests expire after 15 minutes.
* Once approved, the member opens the session/runbook referencing that approval. Approvals are scoped to the target, mode, and permissions requested.

## Locks and recording requirements

* The terminal policy must be enabled and not emergency-locked for any session to start.
* Production sessions are always recorded; recording storage must be available or the session is refused.
* Non-production recording can be required by policy; if storage is down, an authorized policy manager can override for non-production only.

## Expected result

<Check>
  You know in advance when you will be asked for a reason or an approval, and how to satisfy each.
</Check>

## Common failures

<Warning>
  * production sessions require a reason between 10 and 500 characters: enter a reason before connecting.
  * production approval required: request and obtain an approval first (members on approval-gated targets).
  * terminal access is locked: the policy is disabled or emergency-locked.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Access and permissions" href="/terminal/access-and-permissions">
    How terminal permissions are derived from team role, project ownership, per-user grants, and platform admin, and what each permission unlocks.
  </Card>

  <Card title="Runbooks and one-off commands" href="/terminal/runbooks-and-commands">
    Run versioned platform and project runbooks, and execute ad-hoc one-off commands, within the project terminal policy.
  </Card>

  <Card title="Session recordings and history" href="/terminal/recordings-and-history">
    Review, play back, and download terminal session recordings, and audit session history — including how retention and purging work.
  </Card>
</CardGroup>