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

[emooreatx]

Android (0.5.212): after a factory reset the setup self-claim uses the PREVIOUS boot's one-time PIN — captured from latest.log — and the node answers 401 auth.claim.pin_invalid, so the with-AI pass ends with the node unclaimed and announce refused 409 node is not owner-bound. Gate run https://github.com/CIRISAI/CIRISAgent/actions/runs/34272658734 (CIRISAgent release/2.11.0 @ 67404f6c0, ciris-server 0.5.203), android-logcat.txt, verbatim with timestamps:

20:29:04.380 python.stdout: Node fold: OWNERSHIP UNCLAIMED — one-time CLAIM PIN: D8NG-N3YE   (no-AI setup; claim OK)
…factory reset, app restarts…
20:31:05.107 PythonRuntime:  Captured one-time CLAIM PIN from node ownership banner.
20:31:06.111 MainActivity:   Ownership CLAIM PIN captured — stopping node-log tail
20:31:07.043 python.stdout: Node fold: OWNERSHIP UNCLAIMED — one-time CLAIM PIN: VP9G-E6X7   (this boot's PIN — printed AFTER the capture)
…the gate's with-AI --launch restarts the app…
20:32:04.594 PythonRuntime:  Captured one-time CLAIM PIN from node ownership banner.
20:32:05.859 MainActivity:   Ownership CLAIM PIN captured — stopping node-log tail
20:32:19.144 python.stdout: Node fold: OWNERSHIP UNCLAIMED — one-time CLAIM PIN: YY7A-B66Q   (this boot's PIN — 15 s after the capture)
20:32:56.373 CIRISApiClient: [claimRemote] POST http://127.0.0.1:4243/v1/setup/claim-remote node_code=CIRIS-V1-AHG6-7V7L-D… cohort=self owner_session=password
20:32:56.409 CIRISApiClient: [claimRemote] Exception: RuntimeException: status=401 Unauthorized body={"error":"claim-remote failed: target rejected the claim (HTTP 401): {\"error\":\"invalid one-time claim PIN\",\"reason_id\":\"auth.claim.pin_invalid\"}"}
20:32:56.420 SetupViewModel: [ORDER] claim_settled claimed=false (exception, session=setup): claim-remote failed: 401 …

Twice in a row the capture lands before the running node prints its banner: MainActivity.tailNodeLogsForOwnership lists latest.log (and siblings) sorted by lastModified and parses the first CLAIM PIN line it meets — after a restart that file still carries the previous boot's banner, _localClaimPin latches it (if (_localClaimPin.value == null)), the tail stops, and CIRISApp.kt's source order (1: banner snapshot, 2: <home>/claim_pin, 3: await banner) never reaches the file because a value is already there.

The PIN is in a file on disk; the log is not a reliable source for it. The node writes the current PIN to the durable <CIRIS_HOME>/claim_pin (0600, JSON {"pin": …}), names that path as claim_pin_file in its setup status, and rotates it per boot; the desktop and iOS runtimes already read it (readClaimPinFromFileIfMissing). Ask: on Android, read <home>/claim_pin at claim time (the node writes it a few seconds after health answers, so on demand at COMPLETE, not at boot) and stop latching a log-derived PIN ahead of it — or drop the log tail entirely on Android now that the file exists there too. A real user reproduces this with one reset + re-setup on a phone (the 20:31:05 capture is exactly that path).

Consequence in the same run: announce bundle: error -- announce returned 409: {"error":"announce (promote owner-binding) failed: owner-binding validation: node is not owner-bound — claim ownership before announcing …"}, i.e. the node was never claimed, so the with-AI setup ends 6/7.

[emooreatx]

Fixed on main at fc8fb96. Your ruling is the one I implemented, and applied wider than Android.

Two causes, both ours. Android had no readLocalClaimPin() override at all — it fell through to the protocol's null default, so the only PIN it could offer came from tailing latest.log. Desktop and iOS have read <home>/claim_pin for a while; Android never did.

And the provider asked the banner first, file second:

pythonRuntimeProtocol.localClaimPin.value        // log tail
    ?: pythonRuntimeProtocol.readLocalClaimPin() // durable file

A log outlives the boot that wrote it, so a stale tail beat the durable file on every platform — Android is just where a factory reset made the window wide enough to hit. Ordering the file first makes that window unreachable everywhere rather than only where it was observed. The banner stays as the fallback for the case it was added for: the node writes claim_pin a few seconds after health answers, so a very early claim can still find no file.

Both are in the next cut.

[emooreatx]

Did not reproduce on 0.5.213 (gate run https://github.com/CIRISAI/CIRISAgent/actions/runs/34283596992, Android): the post-reset with-AI setup claimed the node and announce bundle: ok -- 3/3 rows federation-visible, where the 0.5.212 run had claim-remote … 401 auth.claim.pin_invalid and then 409 node is not owner-bound.

That is a race resolving the other way, not a fix, and it is the reason to still make the change: the tail latched the previous boot's banner in run 34272658734 because the capture won against the node printing its own PIN (20:32:04 capture vs 20:32:19 banner), and this run the ordering differed. A claim that succeeds or fails on log-line timing is the defect; <CIRIS_HOME>/claim_pin is the artifact the node rotates per boot and names in its setup status, and desktop/iOS already read it. Leaving this open on that basis — happy to be told otherwise if the tail is load-bearing somewhere I cannot see.

[emooreatx]

Correction to my previous comment: this was fixed, not a race resolving the other way. fc8fb96 fix(claim): the claim_pin FILE outranks the log banner is in v0.5.213, which is the build I tested — so the clean claim and announce bundle: ok -- 3/3 on that run are your fix working, and I misread it as luck. Sorry for the noise on your own issue.