Problem

In the macOS Settings dialog, the verification-code input field (digitCodeTextField) passes its raw value straight to the server with no client-side validation — no length cap, no character filter, no trimming. A user pasting a large or non-numeric string will have it sent verbatim in the POST body to /api/v2/auth/magic.

The first-startup code entry screen (CodeStepViewController.mm:158-180) already filters to digits-only and truncates to 6 chars. That same protection is missing in the settings dialog.

Locations

• UI: client_generic/MacBuild/Base.lproj/SettingsDialog.xib:181 — NSTextField with contentType="oneTimeCode" and a "6 digit code" placeholder, but no formatter / no max length.
• Submission: client_generic/MacBuild/ESConfiguration.mm:533-534

  EDreamClient::ValidateCodeResult validateResult =
      EDreamClient::ValidateCodeDetailed(digitCodeTextField.stringValue.UTF8String);

  No NSTextFieldDelegate methods (controlTextDidChange:, etc.) are wired up.
• Network: client_generic/Networking/EDreamClient.cpp:1218-1228 JSON-encodes and POSTs the value to /api/v2/auth/magic.

Why this matters

• Accidental: a stray paste sends a multi-KB (or larger) body to the auth endpoint.
• Adversarial: the field is a low-effort way to send arbitrary payloads at the auth endpoint from a signed/trusted client. Structural injection is blocked (boost::json escapes the value), but anything downstream relying on length/format assumptions of code is exposed.

Suggested fix

Mirror the first-startup behavior in ESConfiguration.mm: add an NSTextFieldDelegate (e.g. controlTextDidChange:) that strips non-digits and truncates digitCodeTextField to 6 characters. ~10 lines.

Server-side input validation on /api/v2/auth/magic should still exist independently — this is just closing the obvious client-side gap.