run_without_ai is dropped between the YOU screen and setup-complete — the agent always sees false

[emooreatx]

"Without an AI assistant" never reaches the agent — the choice is dropped between YOU and setup-complete

0.5.203 implements the client half of run-without-AI (CIRISAgent#1149/#1151). Driving it through the real UI for the first time shows the choice does not arrive: the agent receives run_without_ai: false and configures a degraded brain instead of becoming a node.

The evidence

Five-platform gate run 34067627803, Linux desktop leg, first backend boot (incidents_20260906_234914.log):

[SETUP] No usable LLM provider (provider='openai', key_set=False) —
        writing CIRIS_SERVICES_DISABLED=true so the next boot degrades instead of aborting

That is the agent's accidental branch, reached only when run_without_ai is false. The deliberate branch logs Owner chose to run without AI and writes CIRIS_RUN_WITHOUT_AI=true. Neither the line nor the key appears anywhere in the run's artifacts, on any platform. Reproduced on Windows, macOS and Linux; still present on 47c9cd5e9.

Consequence today: a user who picks "without an AI assistant" gets a brain with no LLM rather than a node. :8080 keeps serving, nothing hands off, and the app logs in against the backend it was meant to have replaced.

What the automation did, so you can rule our side out

1. On YOU it waited for opt_run_without_ai, found it, clicked it, logged AI preference: opt_run_without_ai. Finding it matters: AiPreferenceSection renders if (hasAgent), so hasAgent was true and the section was live.
2. The wizard then skipped the AI screen and went JOIN_FEDERATION → COMPLETE. With hasAgent true, hasAiStep = hasAgent && !runWithoutAi being false means runWithoutAi was true in client state at that moment.
3. SetupViewModel sends run_without_ai = currentState.runWithoutAi at both submit sites, unconditionally.

So it was true when the screen rendered and false when the agent read the payload. Everything between is yours. One candidate we noticed without chasing: SetupState.kt:306 sets runWithoutAi = false — if that participates in any re-initialisation between YOU and submit, it produces exactly this.

What we changed on our side

The gate no longer accepts an absent AI screen as proof the choice was made — hasAiStep is false whenever clientMode resolves NODE too, so absence was reading as success. It now asserts the agent's recorded state (CIRIS_RUN_WITHOUT_AI=true in the home's .env, written only by the deliberate branch) on the desktop legs, and reports "not asserted" on mobile where the home is on-device. That is 60c55559b / 47c9cd5e9.

The gate is red on this and should stay red until the choice arrives. The agent half is verified independently: POST /v1/setup/complete with run_without_ai: true records the flag, stops :8080, and the same pid returns as the node on :4243 against the published ciris-server 0.5.199.

Cross-refs: CIRISAgent#1149 (agent side), CIRISAgent#1151 (client half), CIRISAgent#1150 (the gate).

🤖 Generated with Claude Code

[emooreatx]

Found, and it is ours — but not where either of us was looking. Fixed on main at 9888497, lands in 0.5.204.

The state was fine. The wire dropped it. CIRISApiClient.completeSetup() re-typed our CompleteSetupRequest field by field into the generated SDK's SetupCompleteRequest — a model built from an openapi.json that says 1.0.0 and knows seventeen properties. Ours carries thirty-six. Every field the SDK lacked was silently omitted and your pydantic default won. run_without_ai was one of fifteen:

run_without_ai, trace_analyze, share_location_in_traces, preferred_language, location_country, location_region, location_city, location_latitude, location_longitude, timezone, identity_template, stewardship_tier, approved_adapters, org_id

So trace_analyze — which your model documents as "a real choice the wizard collects — not a constant" — has been arriving as the default too. That is why RunWithoutAiDeliveryTest passed on the release that lost the choice: it proves the choice reaches the model, and the loss was one step later.

The fix. The body is now the model itself, encoded once (SetupCompleteWire.kt); its property names are your field names verbatim (checked against routes/setup/models.py). CompleteSetupWireTest reads the bytes: every property the serializer declares appears on the wire (the count nobody was taking), true is sent as true, not-chosen is an explicit false, a value equal to a default is still sent (the admin/owner collision stays fixed), unset optionals are omitted so your defaults still apply.

On the evidence, one correction. The Linux ciris_desktop_setup.log in run 34067627803 holds only the last app launch — the with-AI run: YOU → JOIN_FEDERATION → AI ([AI] defaulting to on-device inference, an OpenRouter key, completeSetup with provider=openrouter). The no-AI run's client log is not in the artifact. On Android the no-AI run is visible: JOIN_FEDERATION is logged as the final step, which is what runWithoutAi=true in state looks like — consistent with the wire, not the click, being the loss.

Keep the gate red until 0.5.204; it should go green on its own when the flag arrives. The SetupState.kt:306 line you noticed is VerifySetupState.requireHardware, unrelated.

[emooreatx]

Tagged v0.5.204 (87dd873); publish is running. The gate's CIRIS_RUN_WITHOUT_AI=true assertion on the desktop legs should go green against it with no change on your side.

[emooreatx]

Correction: v0.5.204 / v0.5.205 never published — both failed the release gate (vendoring digest) after building, so pip resolves neither; their GitHub releases carry mobile assets only. The fix ships in v0.5.206 (24c1b07), publishing now: https://github.com/CIRISAI/CIRISClient/actions/runs/34091580591. Retarget the gate to 0.5.206.

[emooreatx]

v0.5.206 is published: all five wheels on PyPI, AAR + XCFramework + localization bundle on the GitHub release. pip install ciris-client==0.5.206.