Desktop first-run: 'No server detected' against a SETUP-state backend, then launches a second ciris-server on :8080 and fails on the collision

[emooreatx]

macOS, 0.5.217: on the with-AI first-run leg the app decided no backend was there, launched its own ciris-server on the same port, and then failed startup on the collision it had just created. CIRISAgent run 34312773554 (release/2.11.0 @ aea98e95d, ciris-server 0.5.204). Same family as #52 — "never a second node" — but a different path: the desktop first-run backend on :8080, not the node on :4243.

Our harness starts the backend and waits for it before launching the app:

Server PID: 29500
Agent state: SETUP, healthy: False   (x4)
[OK] Server ready (state: SETUP)
[3/3] Launching desktop app (CIRIS_TEST_MODE=true)...
[OK] desktop test server up at http://localhost:9091

The app then, from ciris_desktop_setup.20260909T051127.log:

115: [PythonRuntime.desktop] No server detected, launching backend...
116: [PythonRuntime.desktop] Launching local ciris-server node...
118: [PythonRuntime.desktop] Node home: /Users/runner/work/_temp/ciris-macos (node listens on :8079, API on :8080)
120: [ERROR][StartupViewModel] [STARTUP] Step 2 FAILED: startServer() -> Cannot start the CIRIS backend: port(s) [8080] are still held by another process a
126: [ERROR][StartupViewModel] [STARTUP] === Startup sequence FAILED: Cannot start the CIRIS backend: port(s) [8080] are still held by another process and 

So the probe concluded "No server detected" against a backend that was up and answering — in SETUP state with healthy: false, which is exactly what a first-run backend reports before the wizard completes. It then launched ciris-server with API on :8080, which cannot bind, and turned that into a hard startup failure: port(s) [8080] are still held by another process and nothing is answering. The wizard never appeared (our leg: wait_for_setup_wizard: Setup wizard did not appear within 45s (last screen 'Startup')), so the with-AI pass was 2/7.

Two observations that might separate cause from symptom:

• healthy: false is not absent. A first-run backend is supposed to be unhealthy — it has no admin user and no configured LLM yet; that is what the wizard is for. If the detection keys on health rather than on "something is listening and answering", every first-run launch is one timing slip away from this.
• The error text contradicts the situation: "still held by another process and nothing is answering" — something was answering on :8080, which is why the port was held. Whatever check produced "nothing is answering" disagrees with the one that found the port busy.

It is intermittent: macOS passed this same leg on the two previous runs, and windows/linux/android pass it every time. macOS is the slowest desktop in our matrix, which fits a race.

Not blocking us right now — I am re-running with an unrelated harness fix and will report whether it recurs. Raising it because a client that launches a second backend on a port it already found busy is the same shape as #52, and on a user's machine the visible result is an app that refuses to start with an instruction to kill -9 their own agent.

[emooreatx]

Fixed on main at ebcd47c. Both of your observations were the diagnosis, and the second one is a defect of mine you caught by reading the error text against the situation.

healthy: false is not absent — and the probe knew only one backend

checkExistingServer() asked /v1/identity alone and required 2xx. That is the node's read API. It got there deliberately: VENDOR DRIFT #15 moved the probe off /v1/system/health because the old one demanded an agent cognitive_state, which a node never reports, so every node boot read as NOT_RUNNING. The move fixed the node and broke the agent — a first-run agent in SETUP does not serve /v1/identity, so a backend that was up and answering read as absent.

Two backends, two readiness endpoints, and a probe that understood one of them at a time. It now asks both, and treats 4xx/5xx as present too: a process that refuses a request is still a process holding the port. Only a refused connection means nothing is there.

I also renamed the state HEALTHY → PRESENT, because the old name is how this happened. That enum only ever decided "is something already on this port", and calling it health invited a probe that answered a different question. Your sentence is now the comment on it.

The contradictory error was mine

"still held by another process and nothing is answering"

You were right that those two halves disagree, and the reason is that the second half was never checked — that text is from #40's port-wait, which knew only that a port was busy. It now asks before blaming anyone, and a held port with a live backend behind it is attached to rather than reported as a stuck shutdown. The kill -9 instruction survives only for the case it was written for: ports held with nothing answering.

On the race

Your reading fits: macOS being slowest widens the window in which a first-run backend is answering but not yet healthy. But the timing is what made it visible, not what made it wrong — the probe would misread a SETUP agent on any platform that got there first. So I would expect this to stop recurring rather than move to a different platform.

714 shared tests green; desktop, Android and wasm targets compile; gates clean. Not in a published version yet — say the word and I will cut, or it can ride with whatever else lands next.