[parawanderer]

Everything in exporter 1.2.0. Five themes, in the order they were found — each one came out of running the previous.

15 files, +1,852 / −38. 441 tests pass; nothing here touches a real account.

---

1. Verbose output says what it exposes, before it prints it

The docs told people -vv output "is what to attach to a bug report" and said nothing about what that contains. It contains escrow records described the way a person recognises them — device name, model and serial — keychain item attributes verbatim, and an identifier for every peer in the account's trust circle.

Not solved by scrubbing, and deliberately not attempted: the text comes from a library reading Apple's structures, so no allow-list can promise a field is safe on every account. What it can do is say so specifically enough to act on — a serial and an acct field are things somebody can find and delete, where "contains personal information" is not.

• Printed by the CLI itself whenever logging is on, in red, at both ends of the run. The copy at the start has scrolled away by the time anyone selects output to paste.
• Colour is skipped when stderr is not a terminal, since the next step is usually piping to a file. NO_COLOR honoured.
• The wizard cannot warn first — it logs at INFO unconditionally, because a windowed build has no console. So the caution goes in the log file, at the top and the bottom, because the file is what travels when somebody is asked to attach it.

Also: UnhandledProtocolError now prints its traceback under -v. It was the one error where the stack is the whole diagnosis — the message names a symptom, and a dozen call sites produce it identically.

2. A typo no longer ends the run

All three prompts made exactly one attempt, and a rejection unwound the entire export — so one wrong character threw away everything before it, and the verification code cannot simply be re-entered once it is gone.

Stage	Cap	The trap
Apple ID + password	3	Apple locks accounts, so the bound is low and both fields are offered again — the ID may be what is wrong
Verification code	3	Re-typing must not request a new code: a resend invalidates the one already on the user's phone
Screen-lock passcode	3	FindMy.py's own advice leads with retrying the same passcode, because the call fails intermittently

Nothing retries on its own. Every attempt is offered, because the caps are Apple's and undocumented — not a thing to establish by experiment on somebody's real account.

The loops live in icloud.py so the wizard gets them too; each entry point supplies its own way of asking, matching how sign-in already takes get_code.

3. Scriptable, without inviting a leaked password

Headless and scriptable are different things. The CLI could already run without a window and still stopped to ask five questions.

--apple-id, --password-file, --passcode-file, --device, --all-tags, --include-my-devices, --non-interactive.

There is deliberately no --password flag, and a test says so. A command line is readable by every user on the machine through ps and lands in shell history. The ways in, worst last: a file whose permissions are checked (or - for stdin), then an environment variable, then being asked.

argparse made that harder than it looks — prefix matching quietly accepted --password hunter2 as --password-file hunter2, failing later on a missing file called hunter2 with the password already in ps. allow_abbrev is off; --out is spelled out as an alias so the useful half survives.

Two more choices worth reviewing:

• A world-readable secret file is refused, not warned about. Permissions are the only reason to prefer a file over a variable, so one without them is worse than what it replaced.
• --all-tags excludes your own iPhones and Macs unless --include-my-devices is given. "All my tags" and "all my tags plus the laptop I am sitting at" are different requests, and only one is what a cron job meant.

The prompt guard lives in prompts rather than at each call site, and a test walks the module asserting every coroutine there is guarded — so a prompt added next year fails that instead of quietly hanging somebody's schedule.

4. The wizard stops calling a wrong password a bug

Entering the wrong password and then choosing Cancel ended in a dialog naming an exception, quoting a log path, and asking the user to open a GitHub issue about their own typo. InvalidCredentialsError and RecoveryError now get plain messages.

Cancel also meant the wrong thing: returning None from a retry callback re-raises Apple's rejection, so somebody whose last action was pressing Cancel was told "Password authentication failed". It now says signing in was stopped.

5. Device naming: tried, refused, removed

Attempted and then taken back out, which is worth reading as a whole rather than as three commits.

FindMy.py gained device_name= and announce_device(), so the entry in the user's Apple device list could read "OpenTagViewer Exporter" rather than a bare MacBookPro. Apple refuses it:

HTTP 401, {'ec': -800012, 'em': 'Push token is invalid.'}

ptkn is the one field the flow omits on purpose. A push token is what makes a registered device trusted for verification codes, and 01-authentication §13 calls that "a boundary to hold rather than a gap to close" — an exporter that became a second factor for somebody's Apple ID is a far larger thing to have compromised.

So the call cannot succeed while that boundary holds, and keeping it meant every fresh install making a doomed request forever. Removed.

Nothing that was working is lost. Signing in registers the device by itself and always did; the announce only ever set the name. §13's own answer is the serial — the one field sign-in controls that a person can read — which is why 0PENTAGXPORT is legible rather than plausible. The row still says the device cannot receive verification codes, which is the boundary being visible.

Two things came out of it and are kept:

• Two real divergences in FindMy.py, now fixed upstream: the announce sent the AOSKit/Xcode client-info variant where §7 requires the akd one, and a User-Agent naming Darwin 18 (macOS 10.14) beside a client info claiming 13.4.1. Neither caused the 401; both were wrong.
• -vv was discarding its own diagnostics. configure_logging enumerated findmy.cloudkit, findmy.keychain, findmy.icloud — every part that had mattered so far, and therefore wrong the first time a new one did. announce_device logs under findmy.reports. Now the package, with aiohttp and asyncio still excluded, and two tests holding it.

docs/findmy-py-announce-401-report.md records the whole thing for the FindMy.py and specification sessions. The open question is for the spec: §7 documents a call that §13's boundary makes unreachable, and it should say so next to the call — otherwise the next implementer rediscovers this from a 401.

---

Version

VERSION = "1.2.0". 1.1.0 is published and current, so this cannot ship under that number — two builds stamping OpenTagViewer.wizard:1.1.0 into exports is exactly the drift rule 9 exists to stop.

1.2.0 rather than 1.1.1 because of §2 and §3; only §4 is patch-shaped. scripts/release_version.py --kind exporter --tag exporter-v1.2.0 passes.

Verification

• 441 tests, of which ~90 are new. Fakes throughout — no account is touched.
• The retry cap is mutation-checked: five tests fail if it goes back to 1.
• Ran against a real Apple account: the export works, the device identity persists, the serial appears in the device list, and the 401 above is the observed behaviour rather than a prediction.
• Nothing Android was compiled; this machine has no toolchain. Nothing here touches app/.
• The macOS-local route's get_key_fallback still needs macOS 14 or older and was not run.

---

PR description summarised by Claude Code.