Cumora 0.2.2
A Sign in with Apple hardening fix, and Windows BYOA agents working end to end.
Sign in with Apple — account linking (#61, @KIDA-MNESIA)
The native Apple sign-in endpoint accepted an email in the request body and used it when Apple's signed token didn't carry one. That value could reach the cross-provider auto-link lookup, which binds an Apple identity to an existing account with a matching email — client-supplied data deciding who you are.
Now only two sources can answer that question: an already-linked Apple sub resolves from the email persisted against it, and an unlinked one requires an email_verified claim in Apple's signed token. The email field is gone from the request contract entirely rather than merely ignored. Returning users are unaffected — they resolve by sub, as before, even when Apple omits the email claim.
Windows BYOA (#63, #64, @bingqilinweimaotai)
Windows agents were broken in both directions.
Prompts in. Windows always takes the one-shot codex exec path, and the prompt was appended to argv through cmd.exe, which split anything containing spaces (unexpected argument 'are') and rejected long ones outright (The command line is too long). Prompts now go through stdin, which codex exec - reads by design. Native .exe engines also skip cmd.exe now instead of routing argv through it; .cmd/.bat shims still get the shell they need, including the nvm-windows case.
Replies out. The per-agent cumora shim was written as a single extensionless Node script, which PowerShell will not resolve as a command through PATHEXT, so every cumora reply from an agent failed. A cumora.cmd launcher is now written alongside it. The injected PATH also used a hard-coded : separator, which is not what Windows uses.
Desktop app auto-updates. BYOA users on Windows need npm i -g cumora@latest and a daemon restart to pick up the fixes (installed services self-update within a few hours).
