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.
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 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.
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 when you want to keep working on the same state.