A launch that will not finish

A launch that sits there is the failure you are most likely to hit and least able to diagnose from the outside. The good news is that it is almost always readable from where it stopped — the launch timeline names each step as it happens, and each step is a different thing going wrong.

Find the step the timeline is stuck on below.

Requested

The launch has been accepted and nothing has picked it up yet. This is nearly always the controller:

• The environment has no controller attached. Signup creates three environments but the setup checklist only connects sandbox — if you are launching into build or deployment, attach a controller to it first.
• The controller is attached but offline: the host slept, was rebooted, or the container was removed.
• The host can no longer reach PlatformSmith — a firewall, proxy or network change.

Check: the environment's controller status. If it is disconnected, restart the controller on its host; if it is gone, use Attach controller on the environment.

Resolving recipe

PlatformSmith is working out which image this launch needs. A stall here usually means something in the project's configuration cannot be resolved — a missing base image, or a repository the Git connection can no longer reach.

Check: the project's source settings, and whether the Git connection still lists repositories.

Starting builder · Building image

An image is being built for you. This step is legitimately slow the first time — minutes, not seconds — and fast afterwards, because later launches reuse the image.

A genuine stall means the build cannot start or cannot finish:

• The build environment has no controller. The most likely cause on a new organization: building happens in your build environment, and the setup checklist never connected one to it. → Attach a controller
• Building requires a Host with Docker environment. A Kubernetes-only setup has nowhere to build.
• The host ran out of disk or memory.
• The project's own build steps are failing.

Check: the builder's logs. It appears in your runtime list as a runtime you did not create — that is expected. → Images and builds

Cloning repository

Your code is being checked out. Stalls here are about repository access:

• The clone cannot authenticate — the Git connection was revoked, or it is a selected-repositories installation that does not include this repository.
• The branch the project points at no longer exists.

Check: the Git connection. Reauthorise usually fixes it.

Starting runtime

The container is being created and given its configuration — including your coding-agent credential. This is where credential problems surface:

• No credential resolves for you. If the organization's only credential is somebody else's personal one, yours resolves to nothing.
• The agent definition names a coding agent you have no credential for — a Claude definition in a Codex-only organization.
• The image cannot be pulled by the host.

Check: Credentials, and whether the definition's coding agent matches the credential you have.

A launch that names no definition fails earlier and more clearly

If your organization has no default coding agent set, the launch is refused up front with a message saying so, rather than stalling here. → No default coding agent yet

Setting up

The container exists and is preparing itself — installing, and running any setup steps your project or agent definition defines. Stalls here are usually about the network inside your environment: setup is waiting on something the container cannot reach.

Remember the container's network is your environment's network, not ours.

Check: the runtime's logs.

It says Ready but my script is still waiting

You are probably reading the wrong field. Which field carries readiness depends on which endpoint you called, and one of them does not return a status at all. → Knowing when a runtime is ready

Still stuck

Collect four things: the project, the environment, the step it stopped on, and roughly when. Those are what anyone helping you will ask for first. → Support