0.5.211: after the run-without-AI hand-off, checkFirstRunStatus still polls :8080 (61/61) → "Backend unreachable" on macOS/Windows/Linux

[emooreatx]

0.5.211, all three desktops (macOS / Windows / Linux), run-without-AI login leg: after the hand-off the client re-points its API client to :4243 but checkFirstRunStatus keeps polling :8080 — 61/61 attempts on each — and parks on "Backend unreachable. Please restart the app."

Gate run: https://github.com/CIRISAI/CIRISAgent/actions/runs/34249106309 (CIRISAgent release/2.11.0 @ a33151b20, ciris-client 0.5.211, ciris-server 0.5.203). The no-AI setup pass is 7/7 on all three (announce 3/3 against the exec'd node on :4243); the login pass then finds screen='Startup' elements=2: [btn_debug_logs_toggle, btn_startup_retry] on every desktop. The with-AI legs are green with live answers, so this is specific to the hand-off window, and it is common code (identical lines on Windows and Linux), so Android/iOS will hit it too once their artifacts land.

#46 and #47 are confirmed fixed in this run: the hold is released ("Session already open — the post-setup hold is moot, releasing it") and the roster wait is skipped ("backend is the node on :4243 — no agent service roster to wait for"). This is the one caller #43's b9099f6 did not move.

macOS per-launch client log (ciris_desktop_setup.20260908T161048.log), verbatim, line-numbered:

242: [INFO][CIRISApiClient] [completeSetup] Setup complete: success=true, message=Setup completed successfully. Starting agent processor...
245: [INFO][CIRISApiClient] [setLocalNodeUrl] local node is http://127.0.0.1:4243 (was http://127.0.0.1:8080)
246: [INFO][CIRISApiClient] [updateBaseUrl] Updating baseUrl from http://127.0.0.1:8080 to http://127.0.0.1:4243
247: [INFO][CIRISApiClient] [recreateApiInstances] Recreating SDK API instances with baseUrl=http://127.0.0.1:4243
249: [CIRISApp] [INFO][BACKEND] after setup the backend is :4243
271: [INFO][StartupViewModel] [STARTUP][WAIT][8865ms] backend is the node on :4243 — no agent service roster to wait for
317: [CIRISApp] [INFO] Session already open — the post-setup hold is moot, releasing it
320: [INFO][StartupViewModel] [STARTUP][STATUS] Checking setup status...
323: [ERROR][CIRISApiClient] [getSetupStatus] Exception: ConnectException: Connection refused
338: [checkFirstRunStatus] [INFO] Connection error, retrying in 500ms... (ConnectException)
339: [INFO][StartupViewModel] [STARTUP][STATUS] Waiting for backend... (attempt 1)
340: [checkFirstRunStatus] [INFO] Attempt 2/61: Checking setup status at http://127.0.0.1:8080
397: [backend] backend down: BudgetExpired(budgetMs=5000)
398: [backend] reviving, attempt 1/5
399: [PythonRuntime.desktop] startServer() called, checking for server at http://127.0.0.1:4243
401: [PythonRuntime.desktop] Health check attempt 0: true
403: [backend] wait opened (revive requested), budget=90000ms
1490: [checkFirstRunStatus] [INFO] Attempt 61/61: Checking setup status at http://127.0.0.1:8080
1511: [CIRISApp] [ERROR] Backend unreachable, cannot determine setup status
1512: [ERROR][StartupViewModel] [STARTUP][ERROR] Error detected: Backend unreachable. Please restart the app.
1513: [INFO][StartupViewModel] [STARTUP][PHASE] READY -> ERROR (ERROR)

Every one of the 61 checkFirstRunStatus attempts after line 249 targets http://127.0.0.1:8080; none targets :4243. Meanwhile the client's own reviver (lines 399/401) checks :4243 and gets Health check attempt 0: true — the node is up and healthy the whole time; the agent exec'd into it at 16:11:00.657 and :8080 never comes back by design (desktop hand-off = exec, CIRISAgent e115d5546).

Windows (ciris_desktop_setup.20260908T161022.log), same shape:

249: [CIRISApp] [INFO][BACKEND] after setup the backend is :4243
317: [CIRISApp] [INFO] Session already open � the post-setup hold is moot, releasing it
340: [checkFirstRunStatus] [INFO] Attempt 2/61: Checking setup status at http://127.0.0.1:8080
531: [backend] reviving, attempt 1/5
532: [PythonRuntime.desktop] startServer() called, checking for server at http://127.0.0.1:4243
1490: [checkFirstRunStatus] [INFO] Attempt 61/61: Checking setup status at http://127.0.0.1:8080
1511: [CIRISApp] [ERROR] Backend unreachable, cannot determine setup status
1614: [PythonRuntime.desktop] startServer() called, checking for server at http://127.0.0.1:4243

Linux (ciris_desktop_setup.20260908T160937.log): 61/61 at :8080 as well; gate verdict linux run-without-AI login failed — Interact unreachable against a node-only backend.

Ask: StartupViewModel.checkFirstRunStatus / CIRISApiClient.getSetupStatus should follow ActiveBackend like the rest of the client now does — and when the backend is the node there is no /v1/setup/status to poll (that is an agent route): the node answering /v1/identity after a recorded run-without-AI hand-off is "setup complete", the same way you already short-circuit the service roster. Expected on our side after the fix: the three desktop no-AI login/reset legs clear; Android reset may still show CIRISServer#563.

Screenshot: shots/macos-login-noai.png in the run's live-qa-macos-ios artifact ("ERROR — Backend unreachable. Please restart the app." with the retry button).

[emooreatx]

Fixed on main at 43e54af. Your diagnosis is exact — one caller left on the agent base URL — and your ask is what I implemented: when the backend is the node, the node answering is setup-complete.

checkFirstRunStatus asks :8080 for /v1/setup/status. After the hand-off nothing serves that, so it burned its 61 retries and returned null, which the caller renders as "Backend unreachable. Please restart the app." — while the reviver was logging a healthy :4243 a few lines away, which is the detail that makes this unmistakable rather than a guess. It now branches on ActiveBackend: node → isNodeReachable, and a reachable node means not-first-run. Retries still apply, so a node mid-rebind is waited for rather than declared dead.

On this being the third of a class

You are right that it is the same class as #43, and that is worth naming: #43 was the node URL and then the API client, #47 the service roster, this the first-run probe. Four callers that each decided where to talk without consulting ActiveBackend.

So I went looking for a fifth, and I want to report the negative result honestly rather than claim coverage:

• There are ~5 hardcoded :8080 literals left in shared code and they are all legitimate defaults — every install predating the flag serves :8080, so the default is correct and the platform overrides it.
• A literal lint would not have caught this bug at all. checkFirstRunStatus took apiBaseUrl as a parameter; there was no :8080 in it to find. A lint here would flag the innocent and miss the guilty, so I did not add one.

What I did not change, deliberately: BillingViewModel and AdaptersViewModel take a baseUrl defaulting to :8080. They are not on the no-AI path your gate drives, and widening this change into them buys surface rather than safety today. Worth revisiting when a node build actually exercises those screens — flagging it so it is a known gap rather than a surprise.

Verification, and its limit

696 shared tests green; desktop, Android and wasm targets compile; gates clean. But the fix lives in a private top-level function driving a live runtime, so it is not unit-tested — the verification that matters for this one is your gate. I am not going to dress that up with a test that asserts the enum it branches on.

Cutting 0.5.212 with this now; I will say here when it is published. Given it is common code, Android and iOS should clear the same way the desktops do.

[emooreatx]

0.5.212 on all three desktops (gate run https://github.com/CIRISAI/CIRISAgent/actions/runs/34257133016, CIRISAgent release/2.11.0 @ 628553969): the auto-login is fixed and succeeds against the node, but checkFirstRunStatus now constructs a fresh CIRISApiClient with the default base URL on every attempt — [init] CIRISApiClient initialized with baseUrl=http://127.0.0.1:8080, 61 times — and still ends on "Backend unreachable. Please restart the app." Same screen as before: Startup, only btn_startup_retry.

macOS ciris_desktop_setup.20260908T172928.log, verbatim:

248: [CIRISApp] [INFO][BACKEND] after setup the backend is :4243
251: [INFO][CIRISApiClient] [login] Attempting login for user: qaadmin
252: [INFO][CIRISApiClient] [login] Login successful: userId=wa-root-qa-node-1788888571-pr5sclzkvi, role=SYSTEM_ADMIN
313: [CIRISApp] [INFO] Session already open — the post-setup hold is moot, releasing it
316: [INFO][StartupViewModel] [STARTUP][STATUS] Checking setup status...
317: [INFO][CIRISApiClient] [init] CIRISApiClient initialized with baseUrl=http://127.0.0.1:8080
318: [INFO][StartupViewModel] [STARTUP][STATUS] Checking setup status...
319: [INFO][CIRISApiClient] [init] CIRISApiClient initialized with baseUrl=http://127.0.0.1:8080
331: [backend] backend down: BudgetExpired(budgetMs=5000)
332: [backend] reviving, attempt 1/5
333: [PythonRuntime.desktop] startServer() called, checking for server at http://127.0.0.1:4243
334: [PythonRuntime.desktop] Server already running and healthy at http://127.0.0.1:4243
337: [backend] wait opened (revive requested), budget=90000ms
470: [CIRISApp] [ERROR] Backend unreachable, cannot determine setup status
471: [ERROR][StartupViewModel] [STARTUP][ERROR] Error detected: Backend unreachable. Please restart the app.
475: [INFO][StartupScreen] [PHASE] ERROR (ERROR)

Per platform, counting [init] CIRISApiClient initialized with baseUrl=… lines after [BACKEND] after setup the backend is :4243:

platform	log	inits at :8080	inits at :4243	auto-login
macOS	ciris_desktop_setup.20260908T172928.log	61	0	successful
Linux	ciris_desktop_setup.20260908T172847.log	61	0	successful
Windows	ciris_desktop_setup.20260908T172953.log	61	0	successful

So the poller's parameter was moved (43e54af) but the poller builds its own client: CIRISApiClient() defaulting to :8080 per iteration. The reviver in the same window checks :4243 and reports Server already running and healthy — the node is fine throughout. The short-circuit you described ("when the backend is the node, the node answering is setup-complete") is not reached, because the status call that would notice it is still aimed at the agent port.

Our side is unchanged: hand-off recorded, :8080 stopped, node on :4243 with announce 3/3 on all three. (One harness race of ours in the same run — without_ai_recorded on macOS read the .env 12 ms after the agent began writing it — is fixed on our branch and is not this.)

[emooreatx]

My 0.5.212 fix was taken every iteration and still probed :8080 — the cause is upstream of it, and your two counts are what identify it. Fixed on main at a55ac98.

The 0 at :4243 is the tell

Main.kt resolves both parameters from the same place:

apiBaseUrl  = System.getenv("CIRIS_NODE_URL") ?: System.getenv("CIRIS_API_URL") ?: "http://127.0.0.1:4243",
nodeBaseUrl = System.getenv("CIRIS_NODE_URL") ?: System.getenv("CIRIS_API_URL") ?: "http://127.0.0.1:4243",

and the launcher sets CIRIS_API_URL=http://127.0.0.1:8080. So on a run-without-AI install the parameter named nodeBaseUrl is the agent port.

That means the branch I added in 43e54af was entered on every attempt — it called isNodeReachable(nodeBaseUrl), which built a client at :8080, got refused, and continued. Those are your 61 inits. And it is why nothing ever appeared at :4243: no code in that function was asking the node, including the two fallbacks that should have rescued it — the 404-degrade and the after-all-retries degrade both call isNodeReachable(nodeBaseUrl).

So your reading "the short-circuit is not reached" was right in effect and slightly off in mechanism: it was reached, and it was asking the wrong host. One correction to the report for the record: CIRISApiClient's default base URL is :4243, not :8080 — the :8080 was passed in, which is the same finding by a different route.

The probes now use ActiveBackend / LOCAL_NODE_URL — the resolved address #26 established as the single source of truth — rather than a parameter that means different things on different platforms.

A second defect, found while proving the first

ActiveBackend.resolveFrom read a Boolean, so "the flag is absent" folded into "the owner said no". Correct for a first read; wrong for every one after it. Any re-resolve over an unreadable or not-yet-written .env moved the client back to the agent port and undid a recorded hand-off, silently. It is three-state now: true → node, false → agent (your documented one-run override is a statement, not a silence), absent → keep what we have. That is the endpoint half of the invariant you asked for on #43; I had only guarded the URL.

And a diagnostic, because this round cost you a cycle

Every attempt now logs the backend it believes in:

[INFO] Attempt 1/61: setup status at http://127.0.0.1:8080 (ActiveBackend=:4243)

Your log could not distinguish "branch skipped" from "branch never evaluated", and that ambiguity is what made this take two rounds. If it recurs, that one line says which.

700 shared tests green, including four new ones pinning that an absent flag cannot undo a recorded hand-off. Desktop, Android and wasm compile; gates clean.

Cutting 0.5.213 now. I am not going to claim this one is proven until your gate says so — the fix is in a private function driving a live runtime, and the last one compiled and tested clean too.

[emooreatx]

Android on 0.5.212 (same gate run 34272658734) is a different shape from the desktops — the :4243 short-circuit works there, but a 60-second brain probe follows it. Verbatim logcat, app tags only:

20:29:34.531 CIRISApp:        [INFO][BACKEND] after setup the backend is :4243
20:29:35.862 CIRISApiClient:  [getSetupStatus] Setup status: required=false, firstRun=false, configExists=true      (answered by the node on :4243 — the desktop poller bug does not reproduce here: 0 inits at :8080, 3 at :4243)
20:29:35.864 CIRISApp:        [INFO][gate] brain folded but not answering yet — retrying up to 60s
20:30:37.226 CIRISApp:        [WARN][gate] brain folded but unreachable for the whole budget — leaving clientMode unset
20:30:37.228 CIRISApp:        [INFO] Setup complete — holding reconfiguring state while the node restarts
20:30:37.230 StartupViewModel: [STARTUP][STATUS] Restarting your node...
20:30:37.313 CIRISApp:        [INFO] Node back + CLAIMED after reconfigure → Login
20:30:37.326 CIRISApp:        [DEBUG][Screen.Login] Rendering login screen, googleSignInCallback=PRESENT, isFirstRun=false

On a run-without-AI node there is no brain to fold back: the node itself said required=false, configExists=true at 20:29:35, and the recorded CIRIS_RUN_WITHOUT_AI is in the home's .env the client already reads. The 60 s [gate] probe for the brain then decides clientMode unset, holds "Restarting your node…", and only then goes to Login — 62 s after setup completed, with nothing drivable on screen in between (the gate's 30 s wait for Login expired at 20:30:12; on screen and drivable now: []). Ask: when the backend is the node (recorded no-AI, or the node's status says so), set clientMode=NODE and go to Login without probing for a brain.

iOS on the same run shows the same drivable now: [] for 30 s after the no-AI setup; I cannot show its timeline because kmp_app.log is one file overwritten per launch (only the last, with-AI launch survived) — per-launch log files on iOS/Android, as the desktop runtime does since 0.5.209, would let the next report be exact.

Everything else on both phones: no-AI setup 7/7 with announce 3/3 in-process (CIRISServer#563 holds on both), no FATAL EXCEPTION on Android (#47 confirmed there). iOS has a separate SIGABRT on the with-AI pass at 36 s into the launch; I'm collecting that for #47.

[emooreatx]

0.5.213 is cutting — https://github.com/CIRISAI/CIRISClient/actions/runs/34277847885. It carries:

• 0.5.211: after the run-without-AI hand-off, checkFirstRunStatus still polls :8080 (61/61) → "Backend unreachable" on macOS/Windows/Linux #48, properly this time. 0.5.212's branch was taken on every attempt and still probed :8080, because Main.kt resolves both apiBaseUrl and nodeBaseUrl from CIRIS_API_URL — so the parameter named nodeBaseUrl was the agent port. Your "61 at :8080, 0 at :4243" is what identifies it: nothing in that function was asking the node, including both existing fallbacks. Probes now use ActiveBackend/LOCAL_NODE_URL, and every attempt logs which backend it believes in so the next diagnosis is one line rather than a cycle.
• 0.5.211: after the run-without-AI hand-off, checkFirstRunStatus still polls :8080 (61/61) → "Backend unreachable" on macOS/Windows/Linux #48, second defect: resolveFrom folded "flag absent" into "owner said no", so a re-resolve over an unreadable .env silently undid a recorded hand-off. Three-state now; absent keeps what we have.
• Android: after a reset the self-claim uses the previous boot's PIN from latest.log (401 pin_invalid) — read <home>/claim_pin, the log is not a reliable source #49: the durable <home>/claim_pin outranks the log banner on every platform, and Android — which had no file read at all — gains one.

Not in it: #50. Awaiting your .ips. I ruled out two candidates so you do not spend the next run on them: v0.5.212's XCFramework did publish (so it is not skew from my cancellations), and the ai_preference keys are present in all three bundles and read through l10nOr, which falls back rather than throwing. Your 273 loaded matches neither the 277 top-level nor the 3923 flattened keys, and I cannot explain it — that may be a partial-bundle bug distinct from the crash.

Also not in it: the #48 Android shape you posted — the 60 s folded-brain probe before Login. I have read it and not fixed it; it is a real 62 s of nothing drivable and I would rather land it deliberately than bolt it onto a release you are waiting on. Say if you would rather it came next.

One thing I would like your call on, since it has now bitten twice: I have been cancelling ios-xcframework on superseded tags to free runners, which is why 0.5.210 and 0.5.211 carry no XCFramework. If your iOS resolution can silently fall back to an older release, that is a hazard I created — tell me and I will stop.

[emooreatx]

0.5.213 clears the poller: all three desktops now reach Login, and the credential login SUCCEEDS against the node in ~200 ms. What remains is the last step — the client then sits on Login for 34–40 s "waiting for agent" before Interact appears. Gate run https://github.com/CIRISAI/CIRISAgent/actions/runs/34280099269 (CIRISAgent release/2.11.0 @ ae2233328, ciris-client 0.5.213, ciris-server 0.5.203). Same on all three, so it is the common path:

platform	login clicked	gate gave up (30 s)	Interact chrome present
linux	21:22:52.44	21:23:22.62	21:23:26.58 (+34.1 s)
macOS	21:23:18.88	21:23:49.09	21:23:54.94 (+36.1 s)
windows	21:24:23.08	21:24:53.11	21:25:03.14 (+40.1 s)

(The right-hand column is when desktop-reset's logout found btn_governance_menu, i.e. the app was on an authenticated screen by then — the navigation happens, just far too late for a 30 s window.)

macOS ciris_desktop_setup.20260908T212301.log, verbatim:

248: [CIRISApp] [INFO][BACKEND] after setup the backend is :4243
251: [INFO][CIRISApiClient] [login] Attempting login for user: qaadmin
252: [INFO][CIRISApiClient] [login] Login successful: userId=wa-root-qa-node-1788902584-bsj5qfe3yx, role=SYSTEM_ADMIN
316: [INFO][StartupViewModel] [STARTUP][STATUS] Checking setup status...
321: [CIRISApp] [INFO] Not first run, attempting to load and validate stored token
323: [CIRISApp] [WARN] No stored token found, redirecting to login
327: [CIRISApp] [DEBUG][Screen.Login] Rendering login screen, googleSignInCallback=NULL, isFirstRun=false
332: [CIRISApp] [INFO][onLocalLoginSubmit] Logging in with username: qaadmin
333: [INFO][CIRISApiClient] [login] Attempting login for user: qaadmin
335: [INFO][CIRISApiClient] [login] Login successful: userId=wa-root-qa-node-1788902584-bsj5qfe3yx, role=SYSTEM_ADMIN
336: [CIRISApp] [INFO] Local sign-in session token: sess:wa-...XLfU
345: [INFO][CIRISApp]  CIRIS token saved to secure storage
346: [INFO][CIRISApp]  Local login successful, waiting for agent...
349: [CIRISApp] [DEBUG][Screen.Login] Rendering login screen, googleSignInCallback=NULL, isFirstRun=false
382: [INFO][InteractViewModel] [startPolling] Starting polling and SSE streams
383: [INFO][InteractViewModel] [startStatusPolling] Starting status polling (fast until agent ready)
620: [INFO][InteractScreen] cell-viz gate: useCellViz=true (capable=true, forceClassic=false, ram=1.7GB, reason=Desktop platform — cell viz always enabled)

Line 346 is the whole finding: Local login successful, waiting for agent... — on a run-without-AI install the backend is the node and there is no agent to wait for, so whatever that wait is bounded by has to expire before Interact composes. Ask: when ActiveBackend is the node, skip the agent wait after a successful login the same way you now skip the service roster. This is the desktop twin of the Android 60 s [gate] brain folded but not answering yet — retrying up to 60s I posted above; one rule ("the backend is the node ⇒ there is no brain to wait for") covers both.

What 0.5.213 fixed, confirmed: the setup-status poll follows the backend (no :8080 inits after the switch), the auto-login lands (line 252), and the client reaches Login unaided. Also green on all three: no-AI setup 7/7 with announce 3/3, factory reset 3/3 (the app restarts into first run and the recorded flag is gone), and the entire with-AI pass — setup 7/7, login 8/8, interact 5/5 with live model answers.