# Troubleshoot Environments Resolve repository access problems, failed builds, missing launch targets, and runtime secret issues. ## The repository picker is empty For GitHub, check both connections: **Settings → Account → General** for personal GitHub, and **Settings → Organization** for organization GitHub. Then check the GitHub App's selected repositories and your own access. Reconnect an expired integration before trying again. A repository marked **Unavailable** is no longer discoverable through your integration. Restore its access or remove it from the Environment. An empty repository may not be selectable until it has a commit. ## A shared launch target is missing Organization scope does not bypass repository permissions. You must have access to every repository in the Environment. Check the selected run identity too: running as a service account changes which Environments are available. Search and filters can also hide results. Clear them before assuming the Environment was deleted. ## The build is queued or needs attention **Queued** means it is waiting for a builder. Open the Environment for progress; do not start another build just to refresh the display. For **Failed**, inspect the reason and output, correct the configuration, and save or retry. For **Update failed**, the previous successful build is still active. See [build status and repair](/environments/manage). If output is withheld or truncated, it is not a complete diagnostic log. Keep the Environment ID, failure category, and timestamps when asking [support@factory.com](mailto:support@factory.com) for help. Do not send secrets. ## Setup cannot authenticate to a private package registry Secrets from **Settings → Account → Secrets** are runtime values, not build-time values. An installation command that needs a private registry token, artifact credential, or cloud login cannot read those secrets during the Environment build. Keep credential-dependent commands out of the build and run them explicitly after starting a session with the appropriate runtime secrets. Do not paste a token into a setup script as a workaround. Environment repository cloning uses its source-control integration separately; it does not make those credentials available to arbitrary setup commands. ## Environments appear in settings but not when starting a session The first build must be Ready and its active provider available. Direct Environment launches also require enabled access, a paid account, and permitted compute. Some organizations allow Environments only as the source for persistent Droid Computers. Ask a manager or owner to check your organization's access, subscription state, region, and compute policy. See [prerequisites](/environments/prerequisites). ## A launch fails because compute is unavailable An Environment snapshot does not reserve running capacity. Compute usage limits or provider capacity can prevent a new instance or computer wake-up. Check the error with a manager or owner rather than rebuilding a healthy Environment. Compute and model usage are separate constraints. ## A secret is missing or has an unexpected value Check **Personal** and **Organization** in **Settings → Account → Secrets**. A personal value with the same name overrides the organization value. Service-account runs do not use your personal secrets. Start a new instance to receive current values. Existing computers require credential refresh and process restart; changing the saved value does not change the environment of an already-running process. Saved values cannot be displayed again, so rotate the value through **Edit** if needed. ## A new session has old code or tools Check the Environment's last successful build and repository commit details. During an update, new sessions continue to use the previous successful snapshot. Rebuild, wait for Ready, then launch a new instance. Changes made inside an existing Computer do not change the Environment baseline, and rebuilding does not update existing Computers. Use a persistent [Droid Computer](/droid-computers/overview) when you want to keep working on the same state. Verify source control, access, and runtime secrets. Inspect diagnostics and repair the baseline.