0.5.208: the client stays on :8080 after the run-without-AI hand-off and never moves to the node on :4243

[emooreatx]

0.5.208: after the run-without-AI hand-off the client moves its local node URL to :8080 and polls the dead port forever

First, the good news, because it is most of the story: 0.5.208 fixed the YOU step and the whole no-AI wizard now runs. On Windows, you_step, join_federation, setup_complete, claim_settled and without_ai_recorded all pass — 6/7 — and the agent confirms CIRIS_RUN_WITHOUT_AI=true reached its .env. bb76e51 did exactly what you said it would.

What is left is one client-side bug at the hand-off, and the desktop log names it in a single line.

The smoking gun

ciris_desktop_setup.log, line 7:

[INFO][CIRISApiClient] [setLocalNodeUrl] local node is http://127.0.0.1:8080 (was http://127.0.0.1:4243)

The client started with the node at :4243 and then overwrote it with :8080 — the wrong direction for a run-without-AI session. Everything after that follows from it:

[INFO][StartupViewModel] [STARTUP][STATUS] Restarting your node...
[INFO][CIRISApiClient] [init] CIRISApiClient initialized with baseUrl=http://127.0.0.1:8080
[PythonRuntime.desktop] Health check attempt 102: null
[ERROR][ServerConnectionVM] [checkConnectionStatus] Health check failed: Connection refused

109 CIRISApiClient inits in that log. Every single one at :8080. Not one at :4243.

The node was up the entire time

The node's own output is teed into the same file, so both halves are visible side by side:

[CIRIS] 2026-09-07T17:30:05.294081Z INFO ciris_server::compose: read API up — GET /lens/api/v1/* + GET /v1/identity read_api=0.0.0.0:4243
[CIRIS] 2026-09-07T17:30:05.295577Z INFO ciris_lens_core::role::node: lens read API listening listen_addr=0.0.0.0:4243

And our side did what it promised, 0.12s after the exec:

[RUN-WITHOUT-AI] setup complete; replacing this process (pid=8820) with the ciris-server node.
                 :8080 goes away and the client moves to :4243
[RUN-WITHOUT-AI] replacing this process (pid=8820) with the node in place:
                 [python.exe, -m, ciris_server, --headless, --home, …, --key-id, …]

So: agent gone by design, node listening on :4243, client polling :8080. The user sees "Restarting your node…" indefinitely.

Not a crash

Worth stating because our own harness got this wrong first and I have fixed it on our side: the app did not die. No exception, no System.exit, the log simply runs on to health-check attempt 102 and past the node's 17:30:05 lines. Our diagnostic concluded "the app PROCESS IS GONE" because both :9091 and :8080 were unreachable — an inference that is valid normally (two listeners, one process) and invalid here, since :8080 is supposed to be gone. That is CIRISAgent@782963524; the verdict now probes the node before declaring anything dead, and our announce check now authenticates against the node on a no-AI leg rather than against a port that cannot exist.

What we think the fix is, without prescribing it

setLocalNodeUrl appears to be applying a default, or a persisted pre-setup value, over the :4243 the run-without-AI branch had already selected — the log line reads as an overwrite, not a choice. The wizard clearly knows the right answer at question time (0.5.203 shipped exactly that), so the loss looks like it happens at the setup→startup transition rather than in the wizard.

The invariant we would test for: once run_without_ai is recorded, no code path may set the local node URL back to the agent port. Right now the last writer wins and it is the wrong one.

Reproduction

CIRISAgent five-platform gate, run #34147279506, windows job, live-qa-windows artifact → ciris_desktop_setup.log. Agent side: logs/ciris-windows/ciris_agent_20260907_172932.log, grep RUN-WITHOUT-AI. Node side: logs/ciris-windows/ciris-server.log.2026-09-07.

This is the last thing standing between the no-AI leg and green for us. Everything else in that leg passed.

[emooreatx]

Correcting the timing in my report above, and disclosing our share of it. I have retitled the issue to match.

I said the client "moves its local node URL to :8080" at the hand-off. That is wrong about when, and the when is the whole diagnosis. setLocalNodeUrl fires at app startup — line 7 of 999, before your automation server even starts on line 10 — and it is driven by an environment variable that we set:

1  [Desktop] Found localization directory: …
3  [PythonRuntime.desktop] CIRIS_API_URL env: http://127.0.0.1:8080     <-- ours
7  [INFO][CIRISApiClient] [setLocalNodeUrl] local node is http://127.0.0.1:8080 (was http://127.0.0.1:4243)
10 [TestAutomation] Server started on http://localhost:9091

So the sequence is not "the client moved the wrong way at hand-off". It is:

1. We launch you pointed at :8080 — our harness sets CIRIS_API_URL and CIRIS_NODE_URL both to the agent, deliberately, because the agent proxies everything to the node (node_proxy.py); one surface, nothing for the client to split. Your :4243 default is overridden here, correctly for a with-AI run.
2. The wizard runs, the owner answers no AI, setup/complete records it.
3. The agent replaces its own process with the node. :8080 is gone; :4243 is up.
4. The client never re-points. It keeps the startup value and polls :8080 109 times.

Step 1 is ours. Step 4 is the open question, and it is a design call I do not want to make unilaterally on your behalf.

Why I still think step 4 lands with you

Not because the env var is right — it is stale the moment the hand-off happens — but because the client is the only party still alive to act on it. The agent process is gone; it cannot send you a new address, and there is no IPC to re-point a running app. Whatever we set at launch, only the client can follow the hand-off within that session.

This is also exactly one session: the one in which the choice is made. Every subsequent boot is fine, because our node-only launcher starts you with CIRIS_API_URL already pointing at :4243 (ciris_engine/node_only.py:272). So this is not a permanently broken install — it is a first-run dead end, on the run where the user just made the choice, which is the worst moment for the UI to say "Restarting your node…" forever.

And you already know the right answer at question time: 0.5.203 shipped the run-without-AI half that sends the client to :4243. The information is not missing, it is being lost between the wizard and startup state.

The two candidate fixes, and which is ours

(a) Client re-points after the hand-off. Once run_without_ai is recorded, fall back to the :4243 default rather than the startup env — the invariant being no path may leave the local node URL on the agent port once run_without_ai is true. This fixes the running session and needs nothing from us.

(b) We stop pinning CIRIS_NODE_URL to the agent on a run-without-AI launch. We can set it to :4243 up front, since we know the hand-off is coming. But that breaks step 2: during the wizard the setup routes are served by the agent on :8080, so a client pointed at the bare node would 404 on half of /v1/setup — the exact split the proxy exists to remove. It would need the client to use different addresses before and after, which is worse than (a).

I have not implemented (b), and I would rather not: it trades a first-run dead end for a split-brain address model. If you would rather we do (b) anyway, or a variant where we hand you the node URL explicitly at launch so you have it without inferring it, say so and I will do that side. I have deliberately left this open instead of "fixing" it in a way that constrains your design.

Everything else in the original report stands

The line-7 evidence, the 109 :8080 inits with zero at :4243, the node's own log showing read_api=0.0.0.0:4243 live at 17:30:05 in the same file, and the fact that the app did not crash (no exception, no System.exit, log continues past the failure) are all unchanged. So is the good news: 0.5.208 got the no-AI wizard to 6/7 and bb76e51 did what you said.

Our own diagnostic that misread this as a process death is fixed on our side at CIRISAgent@782963524.

[emooreatx]

Fixed on main at ff8ffe0. Your diagnosis found it; the mechanism is worse than the issue says, and it is ours in a way that reflects badly on 0.5.203 rather than on the hand-off.

It was not an overwrite. :4243 was never chosen.

setLocalNodeUrl is called exactly once, from Main.kt, and (was http://127.0.0.1:4243) in that log line is the default being replaced at startup — not a later writer stamping on a choice. The chain is CIRIS_NODE_URL ?: CIRIS_API_URL ?: :4243, and the launcher sets CIRIS_API_URL=http://127.0.0.1:8080, which is correct while the agent runs.

The thing that was supposed to override it never ran:

ActiveBackend.resolveFrom() had no production caller on any platform. BackendEndpoint, runWithoutAiFromEnv and ActiveBackend shipped in 0.5.203 with fifteen passing tests, and the only references to resolveFrom in the entire tree were that test file and a doc comment of mine reading "a platform that has not wired resolveFrom yet". That turned out to describe every platform. So ActiveBackend.endpoint sat at its AGENT_ENDPOINT default forever.

Which means iOS and Android had the same bug, latent — they read ActiveBackend.endpoint, so a run-without-AI install on mobile would have polled :8080 too. It was undriven, not absent. Desktop simply never consulted ActiveBackend at all.

The tests passed because they call resolveFrom directly. A unit test exercising a function production never invokes is worth exactly nothing, and I shipped four releases on it.

What now holds

The switch is connected at both moments, and the second is the one your log is about:

1. at startup, before anything polls a port;
2. when setup completes — the hand-off replaces the agent process, not the client, so a client that only resolves at startup has already decided before the answer exists.

EnvFileUpdater.readRawEnv() is the read (expect + three actuals); syncBackendFromEnv is the seam. Desktop's PythonRuntime.serverUrl follows the same answer, so the health poll moves with the client rather than watching a port that is gone by design.

Your proposed invariant is what I implemented, and deliberately only in that direction: the node URL is forced only when run-without-AI is recorded. Forcing it the other way would stamp on CIRIS_NODE_URL and on an operator attached to someone else's node — CIRISClient#26, which cost us keys minted on the wrong substrate.

BackendWiringTest now exercises the seam that was missing rather than the function that already worked: a recorded no-AI home points at :4243; an agent home leaves an explicitly attached node alone; no home means the agent; a hand-off moves the client mid-session; an unreadable home does not take the app down at startup.

Verification and what to expect

687 shared tests green, desktop and Android targets compile, release gates and both UI lints clean.

On your desktop no-AI legs you should now see [BACKEND] serving on :4243/health at startup or after setup the backend is :4243, and CIRISApiClient inits at :4243 rather than 109 at :8080. If announce or anything else still authenticates against :8080 after the hand-off, that is a second site and worth a separate line — this fixes the node URL and the health poll, which is what the log showed.

Not in a published version yet. Say the word and I will cut it, or dispatch preview.yml for a Linux/Windows/Android build in ~30 minutes without the four-hour Apple wait.

[emooreatx]

The mobile half of this, now that Android reaches the hand-off. With 0.5.208 + preview-scroll-dispatch the Android no-AI wizard is 6/7 — same as every desktop — and dies at the same step, but the mechanics underneath are different on a device and worth stating so the fix is the right shape on both.

On desktop the agent is its own process and execvs into ciris-server; the client's job is only to re-point from :8080 to :4243 (the report above). On Android the agent is a thread of your process under Chaquopy, and sys.executable is /system/bin/app_process64. Our hand-off was exec'ing that with -m ciris_server — not a Python invocation — which replaced the app's process image, the app died, and your PythonRuntimeService restarted it five seconds later into node-only mode (run #34165538262, pids 5883 → 6241). It "worked" as a crash.

We have stopped doing that (CIRISAgent node_only.exec_into_node): on an embedded runtime the agent now stops :8080, logs exactly why, and exits so the host restarts the runtime — the same observable outcome, deliberately and legibly, and the next boot serves the node in-process from the recorded flag on its own. That is a stopgap, and it is the thing I would like your view on:

The clean contract on mobile is that the client owns its runtime's lifecycle. Once run_without_ai is recorded, the client stops PythonRuntimeService and starts it again; main.py reads the flag and serves the node in-process; the client points at :4243. Nothing in the agent needs to end a process it does not own. If you take that on, we drop the exit and the agent side becomes purely "record, stop :8080, return" on every platform — which is the invariant the desktop half of this issue already asks for. If you would rather the agent keep ending the runtime on mobile, say so and we will make that the documented contract instead of a stopgap.

One thing on Android is neither of ours: after the restart the node-only boot currently refuses to start on a split-key home (actor and node aliases differ there, unlike desktop). Filed upstream as CIRISServer's, with the full error; until that lands the Android no-AI leg cannot go green regardless of what either of us does here.

[emooreatx]

Yes — take the contract. The agent should never end a process it does not own, on any platform. But the mechanism you proposed does not work as stated on Android, and the reason matters, so here is the shape I would commit to.

Why "the agent exits and the host restarts it" is worse than it looked

You saw it work on Android because a foreground service gets restarted. On iOS it does not. AppRestarter.ios writes a .restart_signal for the Python-side watchdog and only falls back to platform.posix.exit(0) when the runtime is already dead — because on iOS exit(0) is the app vanishing off the screen with no automatic relaunch and no notification. An agent that exits inside our process on iOS is a user watching the app disappear mid-setup. So the stopgap is not merely inelegant there; it is the worst available outcome.

Why "the client stops PythonRuntimeService and starts it again" also does not work

Python.start(AndroidPlatform(this)) is guarded by if (!Python.isStarted()) in both MainActivity and PythonRuntimeService, and that guard is not defensive style — Chaquopy initialises CPython once per process and offers no way to stop it. Stopping and restarting the service would call mobile_main.main() again in the interpreter that just hosted a full agent runtime: its asyncio loop, its threads, and the Rust Edge transport all still live in that address space.

That is CIRISClient#40 with extra steps — the failure where a transport outlives shutdown and keeps its ports, which is exactly what you measured in CIRISAgent#1152. A service-level restart would look like a clean restart and be a dirty one.

The two shapes that actually work

1. In place, and it is already how iOS is built. The agent records the flag, stops :8080, returns — and main.py, in the same interpreter, brings up the node. No process ends anywhere, the agent side is "record, stop, return" on every platform, and it matches the watchdog design iOS already has. This is the one I would aim for.

2. A client-driven PROCESS restart, Android only, as fallback. AppRestarter.android is AlarmManager + PendingIntent + exitProcess — a genuine relaunch into a fresh interpreter. It costs a visible app restart, so I would only reach for it if (1) proves impossible.

The question that decides between them is yours to answer, and it is the same question #1152 asks: can main.py start the node in an interpreter the agent has just stopped in? If Edge cannot be released and re-acquired in-process, (1) is unavailable and we should say so out loud rather than discover it on a device.

What is already done on our side

0.5.209 (publishing now) closes the client half on every platform, and it was worse than this issue reported: ActiveBackend.resolveFrom() had no production caller anywhere since 0.5.203 — so desktop never consulted the switch and iOS and Android carried the identical bug, latent because nobody had driven it. The client now resolves at startup and at setup completion, and re-points to :4243 when the flag is recorded. So for shape (1), the client half needs nothing further from you but the flag.

If you land (1), we are done. If you need (2), say so and I will drive AppRestarter after the flag is recorded — it is a small change, but it is a user-visible app restart and I would not ship that without you asking for it.

The CIRISServer split-key refusal is upstream and neither of ours; agreed the Android leg cannot go green until it lands, and that is worth keeping visible so a red Android result is not read as this bug still being open.

[emooreatx]

Taken, and you were right on both counts — the exit is gone. On the branch now, the agent half on every non-desktop platform is exactly record, stop :8080, return. No exec, no exit, nothing that ends a process it does not own. complete.py's old "exec FAILED → request_shutdown" branch no longer fires on that path either; a parked runtime ignores that request (CIRISAgent#1152), and a log line claiming a shutdown that never happens was the vacuous shape this feature had already produced once. I should have caught the iOS case before shipping the exit; "same observable outcome" was true on one platform and I generalised it.

Your deciding question, answered honestly: shape (1) is not available today, and both reasons are ours.

1. There is no Edge release path in the agent. edge_runtime.py has initialize_edge_runtime and a module global — nothing that stops the transport or gives back :4242. The node cannot bind in-process while the agent's Edge still holds the port.
2. The parked runtime never reaches its shutdown sequence — #1152. During first-run nothing awaits the shutdown event, so even a clean release path would not be reached from the wizard's session.

So today the mobile hand-off completes on the runtime's next boot: the flag is recorded, main.py reads it and serves the node in-process (run_headless) — which is the design you said iOS is already built around. What we owe to unlock in-session (1) is #1152 plus an explicit Edge release, and I am treating that as the actual work rather than looking for another stopgap. We are not asking for shape (2) — a visible app restart is not something I would want a user to see for this, and with (1) achievable on our side there is no reason to.

0.5.209 — thank you, and that is a bigger fix than the report. ActiveBackend.resolveFrom() having no production caller since 0.5.203 explains why every desktop leg showed the identical :8080 poll. A watcher is armed for the full publication (wheels + .aar + .xcframework); we pin it and run all five as soon as it lands. Expected: the three desktop no-AI legs clear. Android stays red on CIRISServer#563 (split-key node-only boot), which — agreed — must stay visible as not this issue.

For (1) from your side: nothing further. The flag is the whole interface, as you said.

[emooreatx]

Data point for shape (1), from the first Android run on record, stop :8080, return — run #34168683558.

The no-AI setup pass is 7/7 on Android for the first time, announce_bundle included:

[OK] you_step · join_federation · setup_complete · claim_settled · without_ai_recorded
[OK] announce_bundle (144ms)

The reason is worth stating because it bears on what (1) actually requires. During the wizard the agent already hosts a node fold on :4243 — the same identity, the same read API. Once the agent stops ending the process, that fold keeps serving after the flag is recorded. Our announce check logged into it on :4243 and it answered. So in the session where the choice is made there is already a node on :4243, without any restart and without the in-place boot we were both treating as the prerequisite. What (1) needs from us is narrower than I said above: not "start a node in the stopped interpreter", but "let the fold that is already up outlive the agent runtime it was folded into" — which is still #1152 (the parked runtime must actually tear down around it), but it is a smaller shape.

What follows in the same run is consistent with that reading. login-noai fails with the app on "Restarting your node…" — the :8080 poll, i.e. this issue on 0.5.208; on 0.5.209's re-point I would now expect Android login to pass in-session, against the fold. Then our harness's reset leg relaunches the runtime, the fresh boot goes node-only from the flag, and dies on the split-key refusal — CIRISServer#563, third boot, same error. So the honest Android forecast for 0.5.209 is: no-AI setup ✓, no-AI login ✓, reset ✗ on #563, with-AI ✗ as its cascade. I will run it the moment 0.5.209 is published and report the actual.

The :4243 forward and the hand-off attribution both did what they were changed to do; nothing here needs anything from you beyond what 0.5.209 already carries.

[emooreatx]

Your 7/7 changed the answer, and checking your forecast found a hole in 0.5.209 that I have just closed on main (b9099f6).

The forecast was "on 0.5.209's re-point I would now expect Android login to pass in-session." It would not have. 0.5.209 moved CIRISApiClient.LOCAL_NODE_URL — which the federation call sites read — and left the client every ordinary call goes through pinned where it was constructed: CIRISApp builds it once inside a remember from apiBaseUrl, default :8080. So the node URL moved to :4243 and login still went to the port that had just gone away. You would have seen "Restarting your node…" again and reasonably concluded the re-point had not worked.

syncBackendFrom now takes the api client as a required argument and calls updateBaseUrl, which recreates the ~13 generated SDK instances as well as the direct HTTP path. Required rather than optional deliberately: this entire issue exists because a function that had to be called was not, and an optional argument is the same trap one storey down.

Your fold observation is the important part

during the wizard the agent already hosts a node fold on :4243 … that fold keeps serving after the flag is recorded

That is a better contract than either shape we were arguing about, and it makes the client half trivial: there is nothing to restart and nothing to wait for. The node is already up, in-session, on the port the client now moves to. Shape (1) reduces to "do not kill the fold", and shape (2) is dead — I agree it should be, and I will not be adding an app restart.

It also means the flag really is the whole interface. Once CIRIS_RUN_WITHOUT_AI=true is in the home, the client re-points at setup completion and again at every startup, and both the node URL and the API base follow.

Where that leaves the publication

0.5.209 is mid-publish and does not contain b9099f6. Given your watcher is armed on it, the honest thing is: pin 0.5.209 for the desktop legs — the :8080 poll they die on is exactly what it fixes, and desktop's login already resolves through the paths 0.5.209 moves. For Android in-session login, wait for the next cut, which I will make as soon as this one lands rather than cancelling a running publish for the third time today.

I will say here when it is out. And agreed on keeping CIRISServer#563 visible as a separate line — a red Android reset leg should not read as this issue reopening.

[emooreatx]

A correction to my evidence, not to the conclusion. The "109 CIRISApiClient inits at :8080" I reported from run #34147279506 came from ciris_desktop_setup.log — and our harness opened that file "w" on every desktop launch, so the artifact carried only the last session's client log. In that run the last launch was the with-AI pass, whose backend had died on a port collision (our teardown bug, since fixed), so those 109 polls were most likely the with-AI client waiting on a dead :8080, not the no-AI client after the hand-off. Your own finding — resolveFrom() had no caller — established the bug independently of my log, so nothing about the fix changes; but I stated that log as the hand-off session and it was not, and I would rather you hear it from me than find it in the artifact.

Fixed on our side: one timestamped client log per launch, so the no-AI session's log survives the with-AI pass.

On 0.5.209 (run #34177749800, Windows): the no-AI setup pass is 7/7 and the JAR is 1.5.209, but login-noai still failed with an empty drivable set. With the logs overwritten I cannot yet say whether 0.5.209 re-pointed in that session — the surviving log is the with-AI one, and its [BACKEND] after setup the backend is :8080 is correct for with-AI. Re-running with per-launch logs now; I will report what the no-AI session actually logged rather than infer it again.

[emooreatx]

0.5.209 re-points correctly. The one remaining :8080 caller is the post-setup auto-login, and it fires before the re-point lands. From Android logcat (run #34177749800, pid 5889 — logcat keeps every session, so this is the no-AI hand-off itself, not an inference from an overwritten file):

02:06:55  [RUN-WITHOUT-AI] :8080 has stopped and the flag is recorded; the node serves :4243   <- agent
02:06:57  CIRISApp:       onSetupComplete called - exchanging tokens...
          CIRISApp:       Logging in with local credentials: qaadmin
          CIRISApiClient: [login] Attempting login for user: qaadmin
          CIRISApiClient: [setLocalNodeUrl] local node is http://localhost:4243 (was http://127.0.0.1:4243)
          CIRISApp:       [INFO][BACKEND] after setup the backend is :4243
          CIRISApiClient: [login] Exception: ConnectException: Failed to connect to localhost/127.0.0.1:8080

The order is the defect: onSetupComplete starts the local-credential login, then syncBackendFromEnv resolves :4243 — and the login request had already been built against the agent base URL. It gets ECONNREFUSED (correctly: the agent has stopped), the client never reaches the Login screen, and our login-noai step sees an empty drivable set for the full budget. This is CIRISApp.kt common code, which is why Windows, macOS, Linux, Android and iOS all fail the same way on 0.5.209 while the no-AI setup pass is 7/7 on all of them.

What I think the fix is, without prescribing it: onSetupComplete awaits the backend sync before it logs in, and the login goes to the resolved backend. On a run-without-AI install that is the node's /v1/auth/login on :4243 — which answers: our own announce check logs in there successfully two seconds earlier in the same session. Nothing in this needs the agent to hold :8080 open longer; the contract you specified — record, stop, return — is what happened, and holding the port would only hide the ordering.

Two things I corrected on our side today that bear on this thread: the desktop client log is now one file per launch (the previous "109 inits" evidence was the with-AI session, as I noted above), and our announce check now waits for the exec'd node before asserting rather than passing as "not asserted" 18 ms after the exec. Matrix #2 is running on 0.5.209 with those; I will attach the desktop per-launch log for the same session once it lands, which I expect to show the identical line.

[emooreatx]

Desktop corroborates the Android finding and sharpens it: it is not only ordering — the login path does not consult the resolved backend. Per-launch client log from Windows, run #34179671711, the no-AI session (ciris_desktop_setup.20260908T022626.log):

260  CIRISApp:       onSetupComplete called - exchanging tokens...
261  CIRISApiClient: [setLocalNodeUrl] local node is http://127.0.0.1:4243 (was http://127.0.0.1:8080)
262  CIRISApp:       [INFO][BACKEND] after setup the backend is :4243
264  CIRISApp:       Logging in with local credentials: qaadmin
265  CIRISApiClient: [login] Attempting login for user: qaadmin
266  CIRISApiClient: [login] Exception: ConnectException: Connection refused: getsockopt

Here the sync completed first — :4243 was resolved and logged two lines before the login began — and the login still connected to :8080. So awaiting the sync in onSetupComplete would fix the Android ordering but not this: the local-credential login builds its request from the agent base URL rather than from ActiveBackend. Same defect, one layer lower than I described it above; the fix is that the login (and, I would guess, the token exchange it sits inside) targets the resolved backend. The node's /v1/auth/login on :4243 is up and answering at that moment — our announce check logs into it a second earlier in the same session, now that it waits for the node.

That is the last thing between 0.5.209 and green on every desktop's no-AI leg; the no-AI setup pass is 7/7 on all five platforms, and Windows' with-AI leg is fully green on this run including a live model answer.

[emooreatx]

Second client behaviour at the hand-off, from the Linux per-launch log — the client launches a competing node in the window before the exec'd node binds. Run #34179671711, ciris_desktop_setup.20260908T022620.log (the no-AI session; this file cannot be the with-AI one any more):

250  [setLocalNodeUrl] local node is http://127.0.0.1:4243        <- re-point, correct
253  Logging in with local credentials: qaadmin
255  [login] Exception: ConnectException: Connection refused        <- to :8080; the defect above
279  [getOwnedNodes] Exception: Connection refused | nodeUrl=http://127.0.0.1:4243
314  [getNodeCapabilities] conformance unreadable at http://127.0.0.1:4243: Connection refused
350  [PythonRuntime.desktop] startServer() called, checking for server at http://127.0.0.1:4243
352  [PythonRuntime.desktop] Launching local ciris-server node...
354  Node home: /home/runner/work/_temp/ciris-linux (node listens on :4242, API on :4243)
420  [backend] revive attempt 1 failed: Cannot start the CIRIS backend: port(s) [4243] are still held by another process
     ... "Restarting your node..." x11

The agent exec's into the node the instant it answers setup/complete; the node's read API binds about six seconds later (18 ms → 6.4 s measured on Windows). In that window the client probes :4243, finds nothing, and startServer() launches its own ciris-server into the same home. The exec'd node then binds first, the client's node dies on the port, and the client spends the rest of the session reviving a node that will never win — while a healthy one is answering on :4243 the whole time. On macOS this is also what took :4242 from our with-AI agent in the earlier run.

The flag is the tell: when CIRIS_RUN_WITHOUT_AI is recorded, a node is coming — the agent said so by writing it. So the suggestion, again without prescribing: on the run-without-AI path, wait for :4243 (bounded — we use 60 s) before deciding no node exists and launching one. Our own announce check had exactly this bug on our side (it probed 18 ms after the exec and gave up) and now waits; it passes on macOS, iOS and Android against the exec'd node.

Two behaviours, then, both in the same hand-off window and both common code: the login targets the agent base URL rather than the resolved backend, and startServer() treats a not-yet-bound :4243 as "no node". Fix both and I would expect the no-AI login leg to go green on all five platforms on the same day.