## TL;DR
Run initialization timing out is a startup handshake problem: the SDK cannot reach or authenticate with the W and B service within its window. Check outbound network and proxy settings from the training machine, confirm the API key is present and valid, and raise the init timeout or switch the run to offline mode with later sync when the network is restricted.

```text
wandb error: 'CommError: Run initialization has timed out' failed to start run
```

## Use this when
- The run or call fails with this symptom: CommError: Run initialization has timed out from wandb.
- You are working on a wandb run starting on a cluster or CI worker and the failure repeats on the same run or configuration.
- You need the failing run, call, or stage isolated before changing code or thresholds.

## Not for this skill when
- A run that times out because the service itself is having an outage, where the fix is offline mode until it recovers.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Test reachability of the W and B API endpoint from the same machine and environment the job runs in. Verify: the endpoint answers or the network block is shown
2. Verify the API key environment is set in the job's environment, not only in an interactive shell. Verify: the job environment carries a valid key
3. Start a minimal run that logs one metric to isolate init from training code. Verify: the minimal run initializes or reproduces the timeout cleanly
4. Apply the fix that matches the cause: proxy settings, a longer init timeout setting, or offline mode with a later sync step. Verify: training runs initialize reliably in the target environment

## Variant phrasings
### wandb run initialization has timed out commerror
The verbatim phrasing.
### wandb init timeout cluster proxy fix
The cluster phrasing.
### wandb commerror run start timeout offline mode
The offline phrasing.

Compatibility: Weights and Biases Python SDK, online and offline run startup

## Why it happens
Initialization negotiates a run with the service before any logging, so anything slow or blocked in that path, DNS, proxies, auth, or a loaded service, consumes the whole timeout. Training machines and clusters are exactly where outbound paths differ from a developer laptop.

## Edge cases / pitfalls
- Shared filesystems under the run directory can stall init; point the run dir at local disk on cluster jobs.
- If only sweep agents time out, check their per-agent environment rather than the sweep controller's.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QVO16-1L0sE3ASQI0VZPVg