Worker not ready / not connecting

If a worker doesn't appear, shows no ready badge, or runs fail to spawn, work through these.

Worker doesn't appear in the Workers tab

Confirm the service is running on the host:

systemctl --user status am-cloud-worker   # or: systemctl status am-cloud-worker

Check the --panel URL and --token are correct.
For a user service that should survive logout, enable linger:
```
sudo loginctl enable-linger "$USER"
```

"probing…" right after connect

Immediately after a worker connects (or reconnects) you may briefly see a neutral probing… badge instead of ready/no‑key. That's expected — the panel hasn't received the first liveness probe yet, so it shows last‑known state rather than falsely alarming "no AI key". It settles within a few seconds; Resync forces it. Only a persistent no AI key badge is a real problem.

Connected, but no "ready" badge

The worker has no harness with a working provider key. Check the harness chips for the reason and fix per provider errors. After setting a key, restart the worker so it re‑probes.

Spawns fail / "no capable worker"

A spawn needs the bus tools. Confirm a2a and a2a-spawn are installed and on the worker's PATH (shown in the worker's infra deps row).

Permission error as root

Some harnesses refuse to bypass approval prompts when running as root. AM handles claude automatically by setting IS_SANDBOX=1 alongside --dangerously-skip-permissions. If you see "--dangerously-skip-permissions cannot be used with root/sudo privileges" in a run:

Make sure the worker's a2a-spawn is up to date (this handling lives there).
Or run the worker as a non‑root user.

Harness installed but probe says "not installed"

The worker resolves harness binaries by PATH and common locations. Ensure the binary is on the service's PATH (a user service inherits a login‑shell PATH; a system service may need an explicit Environment=PATH=...).